Logo Click here to support our advertisers
Click here to support our advertisers
Online Library


Get the weekly email highlights from the most popular journal for developers!
Current issue

All Categories : Java

Chapter 46

The Standard Extension APIs

by Michael Morrison


Up to this point, everything you've learned about Java has been entirely based on what is known as the core Java API, or the Java Base API, version 1.02. This core API currently comprises the entirety of the Java programming environment. JavaSoft recently announced a broad set of extensions to extend this core API in a variety of ways. Some of these extensions will eventually become part of Java 1.1, which is the next major release of Java. Until the official release of Java 1.1, these new extensions will be released individually as standard extensions to the current Java environment. In addition, some of the new extensions will remain as extensions even after the release of Java 1.1 simply because they address development areas that aren't central to the core Java API.

This chapter takes a look at all the new API extensions and what they have to offer you as a Java developer. Most of the API extensions are very new and haven't even reached the specification stage. For this reason, this chapter is meant to give you an idea of where Java is headed with the standard extension APIs. In other words, you may want to check JavaSoft's Web site ( to get the latest scoop on the status of these APIs because they are still in the development stage.

Java API Overview

Java release 1.02, which is the latest Java release as of this writing, is now being referred to by JavaSoft as the core Java API. The core Java API defines the minimal set of functionality a Java implementation must support to be considered Java compliant. For example, when someone undertakes the job of supporting Java on a particular platform, that person must fully implement the core Java API. This guaranteed support for the core API is what allows Java developers the luxury of being able to write Java programs once and have them run on any Java-compliant platform.

In the near future, JavaSoft plans to expand on the core API by introducing new APIs that address more applied development needs. The new APIs cover a wide range of areas and will ultimately save developers a great deal of time by establishing a consistent approach to certain development issues, reducing the need for custom coding. Some of these new APIs will merge with the new core API (Java 1.1); others will remain extensions. Regardless of their ultimate relationship to the core API, the new extension APIs are referred to as the standard extension APIs because they extend the current core API as we know it.

The standard extension APIs are divided into a set of individual APIs that target different development needs. Following are the major components of the standard extension APIs:

  • Enterprise API
  • Commerce API
  • Management API
  • Server API
  • Media API
  • Security API
  • Java Beans API
  • Embedded API

The rest of this chapter explains each of these APIs and how each impacts the Java software platform.

The Enterprise API

Enterprise computing has become increasingly important in recent years as more and more companies realize the importance of integrating their operations electronically. The unique possibilities afforded by the increased usage of the Internet have only served to magnify the popularity of enterprise computing. JavaSoft took note of Java's lack of support for enterprise systems and announced plans for an Enterprise API.

The Java Enterprise API is designed to allow Java programs a formal mechanism for connecting to enterprise information systems. This is a much needed feature in Java because so many corporate computer systems rely heavily on enterprise information sources. In answering this need, the Enterprise API tackles the problem on three fronts. These fronts come in the form of three API subsets:

  • Java Database Connectivity (JDBC)
  • Interface Definition Language (IDL)
  • Remote Method Invocation (RMI)

JavaSoft has recognized the importance of these three API subsets and plans to directly incorporate them into the core Java API at some point in the future.

Java Database Connectivity (JDBC)

The first of the subset APIs of the Enterprise API is Java Database Connectivity (JDBC). JDBC defines a structured interface to Structured Query Language (SQL) databases. SQL databases are databases built on the SQL standard, which is a widely accepted standard that defines a strict protocol for accessing and manipulating data. By supporting SQL, JDBC allows developers to interact with and support a wide range of databases. This means that the specifics of the underlying database platform are pretty much irrelevant when it comes to JDBC, which is very good news to Java developers.

The JDBC API provides Java developers with a consistent approach to accessing SQL databases that is comparable to existing database development techniques. Interacting with a SQL database using JDBC isn't all that much different than interacting with a SQL database using traditional database tools. This should give Java programmers who already have some database experience confidence that they can hit the ground running with JDBC. The JDBC API has already been widely endorsed by industry leaders, including some development tool vendors who have announced future support for JDBC in their development products.

The JDBC API includes classes for common SQL database constructs such as database connections, SQL statements, and result sets. A result set is a group of data retrieved from a database after a user request. JDBC programs will be able to use the familiar SQL programming model of issuing SQL statements and processing the resulting data. The JDBC API depends largely on a driver manager that supports multiple drivers connecting to different databases. JDBC database drivers can either be written entirely in Java or they can be implemented using native methods to bridge Java applications to existing database access libraries.

You can get the latest scoop on JDBC from JavaSoft's JDBC Web site, located at

Interface Definition Language (IDL)

The Interface Definition Language (IDL) subset of the Enterprise API is aimed at providing a way to connect Java client programs to network servers running on other platforms. IDL is an industry standard protocol for client/server communications across different platforms. The primary usage of the IDL API is to transparently connect Java client programs to legacy systems. A legacy system is an outdated system that has yet to be reimplemented using current technologies. Like it or not, there are still plenty of legacy systems in use that house a great deal of important information.

The Java IDL API includes the following components:

  • A client framework that allows Java IDL clients to be designed as either applets or standalone applications
  • A server framework that allows Java applications to act as network servers for IDL clients
  • A development tool that automatically generates stub code for specific remote interfaces

You can get the latest information on IDL from JavaSoft's IDL Web site, located at

Remote Method Invocation (RMI)

The Remote Method Invocation (RMI) component of the Enterprise API defines an interface for invoking object methods in a distributed environment. The RMI API serves a crucial purpose in the Enterprise API by providing full support for remote object communications. The RMI API makes it straightforward for Java developers to add remote computing support to their classes. For the latest information on RMI, check out JavaSoft's RMI Web site, located at

The Commerce API

As the role of the Internet continues to evolve from being an information source to being a retail marketplace, the need for a secure commercial transaction protocol is also growing. Both Internet vendors and shoppers alike are eagerly awaiting the inevitable migration of shopping to the Web. Beyond shopping, there are also other important areas of financial transactions (such as investment trading) that would benefit greatly from a secure standard. JavaSoft has provided an answer to the secure purchasing problem with the Commerce API, a Java API extension that provides the overhead for Java programs to support secure purchasing and financial management.

The Java Commerce API aims to provide developers with an elegant solution to the problem of commercial transactions on the Web. The goal is to make purchasing goods a seamless yet secure part of the Web experience. To this end, the Commerce API is being pushed by JavaSoft as an open, extensible environment for financial management on the Web. The long-term plan for the Commerce API is for integration into the Java software platform partially with the core API and partially as a standard extension. It isn't clear yet which components will make it into the core API and which will remain separate.

The Commerce API consists of the following primary components:

  • Infrastructure. The infrastructure of the Commerce API is basically the architectural framework that defines the interactions between the other components of the API. This infrastructure is also what gives the API its extensibility to support future commerce extensions.
  • Information database. The database component serves as a repository for user information such as payment methods and the user's shipping address. The database component contains encryption features so that user information can be kept completely private. Alternatively, commerce service providers have the option of sharing user information with one another.
  • Payment cassettes. The Commerce API makes use of cassettes, which are software modules that implement specific financial protocols. A payment cassette defines the protocol for making electronic payments. Examples of payment cassettes include credit cards, debit cards, and eventually digital cash. A user could have multiple payment cassettes that represent different payment instruments, much like we carry different payment instruments in our wallets or purses. In fact, one of the classes in the Commerce API specifically models an electronic wallet.
  • Service cassettes. This is the second kind of software module used by the Commerce API to implement specific financial protocols. Service cassettes serve to model any type of value-added financial service such as financial analysis or tax preparation modules. For example, you could feasibly purchase a service cassette to help you balance your electronic checkbook or assess the value of your stock portfolio.
  • Administrative interfaces. This component of the Commerce API includes dialog boxes and other graphical interfaces used to retrieve information from the user and to configure commerce options.

For more information on the Commerce API, check out JavaSoft's Commerce API Web site, located at

The Management API

The Management API is designed to answer the needs of integrated network management systems. It includes a wide range of interfaces, classes, and applets to facilitate the development of integrated management solutions. The primary goal of the Management API is to provide a unified approach to handling the complexities involved in developing and maintaining resources and services on a heterogeneous network. Using the Management API, Java developers will be able to rapidly develop network management applications supporting a wide range of systems on large and often complex networks. JavaSoft plans to keep the Management API as a separate extension from the core API.

The Management API includes the following core components:

  • Admin View Module (AVM). The AVM is an extension of the Java Abstract Windowing Toolkit (AWT) that is enhanced to provide specific support for creating integrated management applications. The classes implemented in the AVM serve as a basis for developing sophisticated graphical user interfaces. For example, the AVM includes support for graphical tables, charts, graphs, and meters.
  • Base object interfaces. The base object interfaces define the core object types used for distributed resources and services in a management system. Using the base object interfaces, developers can define abstractions for a variety of attributes associated with a managed enterprise environment.
  • Managed container interfaces. The managed container interfaces define a means for grouping together managed objects for better organization. This organization facilitates a more group-oriented approach to keeping up with managed resources, which can be a great benefit in complex systems.
  • Managed notification interfaces. The managed notification interfaces define a core foundation of managed event notification services. Developers are free to create more advanced application-specific notification services by extending these services.
  • Managed data interfaces. The managed data interfaces provide a means of linking managed object attributes to relational databases using JDBC. In doing so, the managed data interfaces establish a transparent link between management resources and external databases.
  • Managed protocol interfaces. The managed protocol interfaces use the Java Security APIs and Java RMI to add secure distributed object support to the core functionality provided by the base object interfaces.
  • SNMP interfaces. The Simple Network Management Protocol (SNMP) interfaces extend the managed protocol interfaces to provide support for SNMP agents. SNMP is a relatively simple protocol originally developed to solve communication problems between different types of networks and gather network statistics. Because SNMP is the most popular management protocol in use, its support through the SNMP interfaces is an important part of the Management API.
  • Applet integration interfaces. The applet integration interfaces component of the Management API specifies how Java applets can be integrated with the Management API to provide management solutions. Applet developers use the applet integration interfaces to build management support into their applets.

For more information on the Management API, refer to JavaSoft's Management API Web site, located at

The Server API

After the success of Java and its immediate use for developing client-side applets, JavaSoft decided to take steps to make Java a more viable alternative for server-side applications. The Server API is JavaSoft's answer to the need for more complete server-oriented support in Java. The Server API provides a wide range of server functionality including support for administration, accessibility control, and dynamic resource handling. Also included in the Server API is the Servlet API, which provides a framework for extending servers with servlets. A servlet is a Java object that extends the functionality of an information server, such as an HTTP server. You can think of servlets as the server equivalents of client-side Java applets.

The Servlet API provides the overhead necessary for creating servlets and interfacing them with information servers. The Servlet API is equipped to handle the entire servlet/server relationship, with an emphasis on keeping things stable and simple. All that is required to run servlets is a server that supports the Servlet API.

JavaSoft has grouped the Server and Servlet APIs under their new Internet server framework known as Jeeves. To get more information about the APIs, visit JavaSoft's Jeeves Web site, located at

The Media API

Possibly the weakest area of the core Java API as we know it is its support for media. Currently, the Java API supports only static GIF and JPEG images and wave sounds in the AU sound format. Clearly, this limited media support won't cut it in the long run. Sure, developers can hack their own media implementations to some extent, but they can already do that in a variety of other languages and platforms. Java was supposed to make things easier, right?

JavaSoft realized this weakness and is remedying things with the Media API, which is slated to include support for a dizzying array of media types that will no doubt put Java on the map as a serious multimedia platform. The Media API includes classes that model media types such as full-motion video, audio, 2D and 3D graphics, telephony, and more. Furthermore, the structure of the API is such that many of these media types will rely on the same underlying facilities. For example, all time-based media (such as video and audio) will use the same underlying timing mechanism, meaning that synchronization won't be a problem.

The Media API is designed to be very open and extensible-which is important considering that the world of multimedia is always changing. JavaSoft plans to integrate the Media API into the Java platform both as core API additions and as standard extension APIs.

The following API subsets comprise the Media API:

  • Media Framework API. The Media Framework API handles the low-level timing functionality required by many of the other media APIs. This API includes support for timing and synchronization, both of which are critical to media types that must function together in harmony. Synchronization refers to how different time-based media elements agree with each other in time. For example, it is important for the sound track of a movie to remain synchronized with the picture.
    Also included in the Media Framework API is support for streaming, compression, and live data sources. Streaming is the process of interacting with data while it is still being transferred. For example, a streaming audio player begins playing audio as soon as a certain minimal amount of data has been transferred.
  • 2D Graphics API. The 2D Graphics API extends the functionality of the AWT classes to provide wider support for 2D graphics primitives and a variety of different graphical output devices, such as printers. Another important addition to the 2D Graphics API is the definition of a uniform graphical model that brings many graphics functions into one structure.
  • Animation API. The Animation API uses the 2D Graphics API as a basis for its implementation of animated 2D graphics objects, or sprites. The Animation API also relies on the Media Framework API for maintaining timing and synchronization.
  • 3D Graphics API. The 3D Graphics API provides the overhead necessary to generate high-performance 3D graphics. This API implements 3D graphics by supporting a model of 3D graphical objects that can be rendered at high speeds. The 3D Graphics API also includes support for VRML, which is a very popular 3D modeling language. To pull off all this functionality, the 3D Graphics API relies heavily on the functions provided by many of the other media APIs.
  • Video API. The Video API brings full-motion video to Java. The API provides the framework for managing and processing video in either a streaming or stored scenario.
  • Audio API. Similar to the Video API in some ways, the Audio API also provides support for both streaming and stored media. However, the media supported by the Audio API consists of either sampled or synthesized audio. The Audio API even contains classes for implementing 3D spatial audio.
  • MIDI API. The MIDI (Musical Instrument Digital Interface) API brings timed musical events to Java by way of the popular MIDI standard. MIDI defines a protocol for communicating and storing time-based events, such as those generated by a musical instrument. MIDI is an efficient way to represent both musical pieces as well as more general timing resources. Expect to hear the Web much differently once this API catches on!
  • Share API. The Share API is probably the most interesting of the media APIs, simply because it's the least obvious. It defines a means by which live, multiparty communication can take place over a network. The Share API provides support for both synchronization and session management. I wouldn't be surprised to see multiplayer games and "chat" applets take on a new feel once this API is out.
  • Telephony API. The Telephony API provides Java with the ability to interact with telephones. Most of the important telephone functions are supported in this API, including teleconferencing and caller ID, among others.

The Security API

The eagerly awaited Security API will hopefully remedy one of the biggest limitations of Java applets: the inability to read or write files locally. With full support for cryptography, digital signatures, and authentication, Java developers should be able to leverage security issues to some extent and move away from the seemingly overprotective solution currently in place. Cryptography encompasses the algorithms and techniques used to render data unrecognizable in the hands of unauthorized parties, thereby enforcing information privacy. A digital signature is an electronic identification technique that serves much the same purpose as a handwritten signature. Authentication is the process of verifying an action based on a security check.

The cryptographic functions built into the Security API are isolated from the programmatic interface used by applets that want to make security decisions. This layering allows the cryptographic functions to be replaced by third-party alternatives without impacting anything at the applet level, thereby giving Java developers more options when it comes to their security needs. The Security API will eventually be incorporated directly into the core Java API.

The Java Beans API

For some time now, the software development community has been pushing the idea of re-usable components. In case you've missed the hype, a component is a reusable piece of software that can be easily assembled with other components to create applications with much greater development efficiency. This notion of reusing carefully packaged software was borrowed to some extent from the assembly-line approach that became so popular in America during the industrial revolution-well before the modern computer era. The idea as applied to software is to build small, reusable components once and then reuse them as much as possible, thereby streamlining the entire development process.

JavaSoft's Java Beans technology is a platform-independent component technology based entirely on the Java platform. The Java Beans technology promises to take the component software assembly paradigm to a new level. As of this writing, the Java Beans specification is close to completion with a preliminary API release expected soon after. Java Beans is being implemented as an architecture and platform-dependent API for creating and using dynamic Java software components. Java Beans picks up where other component technologies have left off, using the portable Java platform as the basis for providing a complete component software solution that is readily applicable to the online world.

The Goal of Java Beans

Following the rapid success of the Java runtime system and programming language, JavaSoft realized the importance of developing a complete component technology solution. Their answer is the Java Beans technology, whose design goals can be summarized by the following list of requirements:

  • Compact and easy to create and use
  • Fully portable
  • Builds on the inherent strengths of Java
  • Leverages robust distributed computing mechanisms
  • Supports flexible design-time component editors

The first requirement of Java Beans (to be compact) is based on the fact that Java Beans components will often be used in distributed environments where entire components may be transferred across a low bandwidth Internet connection. Clearly, components must be as compact as possible to facilitate a reasonable transfer time. The second part of this goal relates to the ease in which the components are built and used. It's not such a stretch to imagine components that are easy to use, but creating a component architecture that makes it easy to build components is a different issue altogether. Existing attempts at component software have often been plagued by complex programming APIs that make it difficult for developers to create components without chronic headaches. So Java Beans components must be not only easy to use, but also easy to develop. For you and me, this is a critical requirement because it means fewer ulcers and more time to embellish components with frilly features.

Java Beans components are largely based on the class structure already in use with traditional Java applet programming, which is an enormous benefit to those of us heavily investing our time and energy in learning Java. JavaSoft has promised that Java applets designed around the AWT package will easily scale to new Java Beans components. This also has the positive side effect of making Java Beans components very compact because Java applets are already very efficient in terms of size.

The second major goal of Java Beans is to be fully portable. JavaSoft is in the process of finalizing a Java Beans API that defines the specific component framework for Java Beans components. The Java Beans API, coupled with the platform-independent Java system it is based on, will comprise the platform-independent component solution alluded to earlier. As a result, developers do not have to worry about including platform-specific libraries with their Java applets. The end result will be reusable components that unify the world of computing under one happy, peaceful umbrella. Okay, maybe that's asking a little too much-I'll settle for just being able to develop a component and have it run unmodified on any Java-supported system.

The existing Java architecture already offers a wide range of benefits easily applied to components. One of the more important, but rarely mentioned, features of Java is its built-in class discovery mechanism, which allows objects to interact with each other dynamically. This results in a system in which objects can be integrated with each other independently of their respective origins or development history. The class discovery mechanism is not just a neat feature of Java, it is a necessary requirement in any component architecture. It is fortunate for Java Beans that this functionality is already provided by Java at no additional cost. Other component architectures have had to implement messy registration mechanisms to achieve the same result.

Another example of Java Beans inheriting existing Java functionality is persistence, the ability for an object to store and retrieve its internal state. Persistence is handled automatically in Java Beans by simply using the serialization mechanism already present in Java. Alternatively, developers can create customized persistence solutions whenever necessary.

Although not a core element of the Java Beans architecture, support for distributed computing is a major issue with Java Beans. Because distributed computing requires relatively complex solutions attributed to the complex nature of distributed systems, Java Beans leverages the usage of external distributed approaches based on need. In other words, Java Beans allows developers to use distributed computing mechanisms whenever necessary but it doesn't overburden itself with core support for distributed computing. This may seem like the Java Beans architects are being lazy, but in fact, it is this very design approach that allows Java Beans components to be very compact because distributed computing solutions inevitably require much more overhead.

Java Beans component developers have the option of selecting the distributed computing approach that best fits their needs. JavaSoft provides a distributed computing solution in their Remote Method Invocation (RMI) technology, which is part of the Enterprise API, but Java Beans developers are in no way handcuffed to this solution. Other options include CORBA (Common Object Request Broker Architecture) and Microsoft's DCOM (Distributed Component Object Model), among others. The point is that distributed computing has been cleanly abstracted from Java Beans to keep things tight while still allowing developers who require distributed support a wide range of options.

The final design goal of Java Beans deals with design-time issues and how developers build applications using Java Beans components. The Java Beans architecture includes support for specifying design-time properties and editing mechanisms to better facilitate visual editing of Java Beans components. The result is that developers will be able to use visual tools to assemble and modify Java Beans components in a seamless fashion, much like existing PC visual tools work with components such as VBX or OCX controls. In this way, component developers specify the way in which the components are to be used and manipulated in a development environment. This feature alone will officially usher in the usage of professional visual editors and significantly boost the productivity of applications developers.

How Java Beans Relates to Java

Many developers not completely familiar with the idea of software components will likely be confused by Java Beans's relationship to Java. Hasn't Java been touted as an object-oriented technology capable of serving up reusable objects? Yes and no. Yes, Java provides a means of building reusable objects, but there are few rules or standards governing how objects interact with each other. Java Beans builds on the existing design of Java by specifying a rich set of mechanisms for interaction between objects, along with common actions that most objects must support, such as persistence and event handling.

Although the current Java component model is not bad, it is relatively limited in regard to delivering true reusability and interoperability. At the object level, there is really no straightforward mechanism for creating reusable Java objects that can interact with other objects dynamically in a consistent fashion. The closest thing you can do in Java is to create applets and attempt to allow them to communicate with each other on a Web page, which isn't a very straightforward task. Java Beans provides the framework by which this communication can take place with ease. Even more important is the fact that Java Beans components can be easily tweaked using a standard set of well-defined properties. Basically, Java Beans merges the power of full-blown Java applets with the compactness and reusability of Java AWT components such as buttons.

Java Beans components aren't limited to visual objects such as buttons, however. You can just as easily develop nonvisual Java Beans components that perform some background function in concert with other components. In this way, Java Beans merges the power of visual Java applets with nonvisual Java applications under a consistent component framework.

Just in case you're wondering what a nonvisual component is, it's any component that doesn't have visible output. When thinking of components in terms of AWT objects like buttons and menus, this may seem a little strange. However, keep in mind that a component is simply a tightly packaged program and has no specific requirement of being visual. A good example of a nonvisual component is a timer component that fires timing events at specified intervals. Timer components are very popular in other component development environments such as Microsoft Visual Basic.

By using visual tools, you can use a variety of Java Beans components without necessarily writing any code. This ability to use a variety of components together regardless of their origin is an enhancement to the current Java model. You can certainly use other prebuilt objects in Java, but you must have an intimate knowledge of the object's interface. Additionally, you must integrate the object into your code programmatically. Java Beans components expose their own interfaces visually, providing a means to edit their properties without programming. Furthermore, when you use a visual editor, you can simply "drop" a Java Beans component directly into an application without writing any code. This is an entirely new level of flexibility and reuse not previously possible in Java alone.

The Nuts and Bolts of Java Beans

Okay, I've rambled enough about Java Beans from the standpoint of what it does and why it's cool. Let's focus now on some specifics regarding how all this is possible. Keep in mind that Java Beans is ultimately a programming interface, meaning that all its features are implemented as extensions to the standard Java class library. The Java Beans API itself is merely a suite of smaller APIs devoted to specific functions, or services. Following is a list of the main component services in the Java Beans API that are necessary to facilitate all the features you've been learning about:

  • GUI-merging APIs. The GUI-merging APIs provide a means for a component to merge its GUI elements with a container document, which is usually just the Web page containing the component. A container document is a document (typically one in HTML) containing Java Beans components that serves as a parent for all the components it contains. Most container documents have menus and toolbars that display any special features provided by the component. The GUI-merging APIs allow the component to add features to the container document's menu and toolbar. These APIs also define the mechanism facilitating space negotiations between components and their containers. In other words, the GUI-merging APIs also define the layout properties for components.
  • Persistence APIs. The persistence APIs specify the mechanism by which components can be stored and retrieved within the context of a containing document. By default, components inherit the automatic serialization mechanism provided by Java. Developers are also free to design more elaborate persistence solutions based on the specific needs of their components.
  • Event-handling APIs. The event-handling APIs specify an event-driven architecture that defines how components interact with each other. The Java AWT already includes a powerful event-handling model, which serves as the basis for the event-handling component APIs. These APIs are critical in allowing components the freedom to interact with each other in a consistent fashion.
  • Introspection APIs. The introspection APIs define the techniques by which components make their internal structure readily available at design time. These APIs consist of the functionality necessary to allow development tools to query a component for its internal state-including the interfaces, methods, and member variables that comprise the component. The APIs are divided into two distinct sections based on the level at which they are being used. For example, the low-level introspection APIs allow development tools direct access to component internals, which is a function you wouldn't necessarily want in the hands of component users. The high-level APIs use the low-level APIs to determine which parts of a component are exported for user modification. Although development tools will undoubtedly make use of both APIs, these tools will use only the high-level APIs when providing component information to the user.
  • Application-builder support APIs. The application-builder support APIs provide the overhead necessary for editing and manipulating components at design time. These APIs are used largely by visual development tools to provide a means to visually lay out and edit components while constructing an application. The section of a component providing visual editing capabilities is specifically designed to be physically separate from the component itself. This arrangement is so that standalone runtime components can be as compact as possible. In a purely runtime environment, components are transferred with only the necessary runtime component. Developers who want to use the design-time component facilities can easily acquire the design-time portion of the component.

By understanding these services and how they work, you'll have much more insight into exactly the type of technology Java Beans is. Each of these services is implemented in the form of smaller APIs contained within the larger Java Beans API. For the latest information on the Java Beans API, refer to JavaSoft's Java Beans Web site, located at

The Embedded API

The last of the standard extension APIs is the Embedded API, which defines a minimal set of Java functionality specifically targeted for embedded systems applications, such as consumer electronics devices. An embedded system is a scaled-down computer system programmed to perform a particular function within an electronic device. The Embedded API is the only API that doesn't really add anything to the Java core API. In fact, the Embedded API will more than likely be a subset of the core API because only a partial amount of the core functionality is needed in embedded applications. For example, because most embedded systems have no graphical output to speak of, the entire AWT is really unnecessary. Likewise, a network connection is unlikely in an embedded system, so there is no need to include the Java networking package.

More than likely, the Embedded API will consist of the following packages from the core API: language, utilities, and I/O. Beyond those, it's possible that Embedded API extensions could be developed to support specialized networking and output requirements. Because the Embedded API is itself a subset of the core API, it will more than likely be treated as an extension API.


In this chapter, you learned about the standard extension APIs that are planned to expand Java in a variety of directions. These APIs will no doubt boost the appeal of Java to new levels because developers will have much more reusable code to leverage when building custom applications and applets. Although this will ultimately mean more learning on the part of developers, it will also result in less time spent writing code that is best suited to a standard extension. Knowing this, many developers will be forced to rethink their current plans based on the availability of the standard extension APIs because there's no need to reinvent the wheel if it's already in the works.

As you learned in this chapter, some of the standard extension APIs will be merged into the core Java API. Much of this merging will no doubt occur in the next major release of Java (Java 1.1). Even though Java 1.1 isn't available at the time of this writing, you can begin using the standard extension APIs as they become available. Stay tuned to JavaSoft's Web site ( for the latest news on the standard extension APIs and Java 1.1.

If these new extensions to Java have gotten you excited about the future of Java, you may be eager to read on. Chapter 47, "The Scoop on JavaOS, Java Microprocessors, and JAR Files," takes a look at some interesting new technologies related to Java that you may not have heard about yet-including a Java operating system, Java microprocessors, and a new Java fileformat.

Ruler image
Contact with questions or comments.
Copyright 1998 EarthWeb Inc., All rights reserved.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.
Click here for more info

Click here for more info