Java 1.1 Unleashed - 57 - Java into the Future by Michael Morrison IN THIS CHAPTER Java API Overview JavaOS Java Microprocessors This chapter wraps up your journey through Java by peering into the crystal ball and taking a look at what lies ahead for Java. More specifically, this chapter discusses new API extensions for Java development, the JavaOS operating system, and Java microprocessors. Most of the new API extensions are available in white-paper form, with early implementations becoming available in the near future. If you aren't familiar with white papers, they are technical documents describing the goals of a new technology. The JavaOS is a new compact operating system based on and fully supporting the Java platform. Java microprocessors are full-blown microprocessors geared toward supporting the Java virtual machine. The emerging Java technologies you learn about in this chapter are still in their early stages as of this writing, which means that I can give you only a preliminary look at what they have to offer. Nevertheless, you should be able to take from this chapter a better understanding of where Java is headed and what it might mean to your own development efforts. You should check out JavaSoft's Web site (www.javasoft.com) to get the latest scoop on the status of these technologies; this site will always contain the most up-to-date information regarding these technologies. Java API Overview Java version 1.1, 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 having 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 may merge with the core API in a future release of Java; other APIs 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: Commerce API Management API Server API Media API Embedded API The following sections explain each of these APIs and how they impact the Java software platform. 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 can benefit greatly from a secure standard. JavaSoft has provided an answer to the problem of secure purchasing 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 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 can 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 Service cassettes are 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 can 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 this URL: http://www.javasoft.com/products/commerce/ 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 can 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), 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 visual gauges. 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 way to group 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 develop more advanced application-specific notification services by extending these services. Managed data interfaces.The managed data interfaces provide a way to link 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. Simple Network Management Protocol (SNMP) interfaces The 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 this URL: http://www.javasoft.com/products/JavaManagement/ 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 its new Internet server framework known as Jeeves. To get more information about the APIs, check out Chapter 55, "Serving the Net with Jeeves." You may also want to visit JavaSoft's Jeeves Web site, located at this URL: http://jeeves.javasoft.com/products/java-server/webserver/index.shtml 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. Musical Instrument Digital Interface (MIDI) API.The MIDI 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 gives Java the capability to interact with telephones. Most important telephone functions are supported in this API, including teleconferencing and caller ID, among others. 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 part 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. JavaOS Even though Java has been touted largely as a neat new programming language, it is, in fact, much more than that. Java is also a very powerful and compact runtime system that, in many ways, mimics the facilities provided by a full-blown operating system. Knowing this, it wasn't a complete surprise to some that JavaSoft decided to build a complete operating system around the Java technology. This new operating system is called JavaOS and is described by JavaSoft as "a highly compact operating system designed to run Java applications directly on micro-processors in anything from net computers to pagers." JavaOS is no doubt intended to ride the wave created by Java and its insanely rapid success. However, don't let that statement mislead you into thinking that JavaOS is any less legitimate than the technology it is built on. The idea of building a complete operating system on top of the existing Java technology makes perfect sense. The applications of a compact, efficient operating system that can natively run Java programs are far and wide. In fact, JavaSoft has already made mention of a variety of devices to which the JavaOS technology could be easily applied. These devices include everything from networked computers to cellular telephones; basically any device that can benefit from a compact operating system and support for a powerful programming language like Java. Overhead JavaOS has been described by JavaSoft as just enough of an operating system to run the Java virtual machine. With this minimal design goal, it stands to reason that JavaSoft is targeting consumer electronic devices with the JavaOS technology. As part of this approach, JavaOS is specifically designed to be fully ROMable, meaning that it will work well in the embedded systems common to electronic devices. A ROMable software technology is one that can be implemented in read-only memory (ROM). ROM is commonly used in electronic devices to store executable system code because there is typically no other storage means beyond random access memory (RAM), which is temporary. JavaOS has been touted as being able to run with as little as 512K of ROM and 256K of RAM in an embedded environment. Likewise, an entire JavaOS system running on a networked computer requires only 4M of ROM and 4M of RAM. These last figures include space for JavaOS, the HotJava Web browser, and a cache for downloading Web content and applets. JavaOS's minimal requirements set the stage for some unique products such as compact personal digital assistants (PDAs) with complete Internet support. Industry Support Because of the success of Java, JavaOS is able to enjoy industry support before its availability in even a preliminary form. An impressive group of technology companies have already announced plans to license JavaOS. Likewise, an equally important group of software tools companies have announced plans to provide development tools for JavaOS. These two areas of support provide the one-two punch necessary for JavaOS to be a success. JavaSoft is already working with the software tools companies to define a set of APIs for developing applications for JavaOS. Major players on the Java development scene have already announced intentions to enhance their development environments to support JavaOS embedded systems development. This is a pretty major step in the embedded programming world, where many development tools are still fairly primitive compared to the visual tools used by computer applications developers. NOTE: On a similar front, both the Solaris and Windows platforms are slated to include full support for Java at the operating system level. However, this support will be aimed more at supporting the Java runtime system than serving as an implementation of JavaOS. Java Microprocessors As if Sun weren't branching out enough with JavaOS, the company surprised the microprocessor world last year by announcing the development of a line of microprocessors optimized for Java. Microprocessors aren't new to Sun, whose Sun Microelectronics division is responsible for the popular SPARC line of microprocessors. However, the idea of Sun Microelectronics developing microprocessors specifically to support Java no doubt caught a lot of people off guard, including other microprocessor companies! NOTE: Just so you don't get confused, both JavaSoft and Sun Microelectronics are divisions of Sun Microsystems. Whenever I refer to Sun, I'm referring to the company at large. Java microprocessors are quite obviously yet another move on Sun's part to capitalize on the success of Java. However, as it does with JavaOS, Sun legitimately has an interesting and potentially lucrative angle in developing Java microprocessors. As it is for JavaOS, the primary target application for Java microprocessors is in embedded systems. Speed is a very critical factor in embedded systems, primarily because of the limited horsepower available in these small systems. Java microprocessors have the potential to significantly increase performance because they are being designed around the highly efficient Java technology. Contrast this with other embedded microprocessors that typically have a more generic design. Sun is pushing Java microprocessors based on a new microprocessor product paradigm: simple, secure, and small. Add to this Sun's promise to deliver Java microprocessors at a fraction of the cost of traditional microprocessors. Sun is clearly appealing to the consumer electronics market, where a compact, low-cost microprocessor would probably rock a lot of boats. Sun has also announced the development of a full range of component-level and board-level products to support the microprocessors. Although the prospect of a Java microprocessor may seem strange at first, it's not hard to see Sun's motivation. By 1999, the average American home is expected to contain between 50 and 100 microcontrollers. Worldwide, there are also expected to be more than 145 million cellular phone users, with each phone containing at least one microcontroller. And each microcontroller contains at least one microprocessor. Are you starting to get the picture? NOTE: A microcontroller is a miniature computer system, usually implemented on a single circuit board, scaled down to support a limited function such as those required by consumer electronic devices. The Java processor family consists of three lines of microprocessors: picoJAVA microJAVA UltraJAVA The next few sections describe these different processor lines and the application for which each is targeted. picoJAVA The specification for a minimal Java microprocessor is called picoJAVA and serves as the basic design for all Sun's microprocessors. picoJAVA isn't a physical processor that Sun intends to manufacture and sell; rather, it is the core specification on which all Java microprocessors will be designed and built. The picoJAVA specification will be made readily available for licensing to other chip manufacturers who want to develop their own Java microprocessors. The picoJAVA specification is geared toward a microprocessor with the best price/performance that fully supports the Java virtual machine. microJAVA The first physical microprocessor in the works at Sun is microJAVA, which builds application-specific I/O, memory, communications, and control functions onto the picoJAVA core. microJAVA processors are expected to cost anywhere from $25 to $100, which makes them good candidates for a wide range of electronic devices such as telecommunications equipment and other nonnetwork applications such as printers and video games. UltraJAVA Sun's high-end Java microprocessor offering is called UltraJAVA. It is designed to encompass the very fastest Java processors available. The UltraJAVA processor line includes support for advanced graphics by virtue of Sun's Visual Instruction Set (VIS), which defines high- performance hardware graphics extensions. Not surprisingly, the UltraJAVA line of processors is primarily targeting high-end 3D graphics and multimedia applications. Even with an expected cost starting at $100, the UltraJAVA processor line may still be a bargain. Summary In this chapter, you broke away from the programming aspects of Java and learned about some new technologies based on the Java framework. The first of these is the standard extension APIs, which 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 these new APIs ultimately mean more learning curves for developers, they also result in less time spent writing code when that code 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. You also learned about JavaOS, a new operating system based entirely on the Java virtual machine. You then took a look at the new Java microprocessors, which aim to be the first physical Java implementation on silicon. Although JavaOS and Java microprocessors may not directly impact your Java development efforts in the immediate future, they will no doubt play a significant role in Java reaching its maturity as a technology with widespread application. That's reason enough for me to stay informed about the status of these technologies!

©Copyright, Macmillan Computer Publishing. All rights reserved.