by Michael Morrison
This last lesson of the bonus week peers into the crystal ball and takes a look at some of the emerging Java technologies. Today you'll learn about a few of the latest groundbreaking Java technologies and what impact they will have on Java as we know it. By looking into the future, you can better gauge where to aim your resources in the present, so today's lesson attempts to give you a rough sketch of a few of the major new and pending products that will no doubt play a significant role in the future of Java.
Today's lesson covers the following major topics:
The Java technologies you'll learn about today are still in their early stages as of this writing, which means I can give you only a preliminary look at what they have to offer. Nevertheless, you should still be able to take from this lesson a better understanding of where Java is headed and what it might mean to your own development efforts.
For some time now, the software development community has been
pushing the idea of reusable components. In case you've missed
the hype, a component is a reusable piece of software that
can be easily assembled 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 the United States 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.
| New Term |
A software component is a piece of software isolated into a discrete, easily reusable structure. |
Although component software has its merits, fully reusable software has yet to really establish itself; this is so for a variety of reasons, not the least of which is the fact that the software industry is still very young compared to the industries carved out in the industrial revolution. It stands to reason that it should take time to iron out the kinks in the whole software- production process. If you're like me, you'll embrace the rapid changes taking place in the software world and relish the fact that you are a part of a revolution of sorts-an information revolution. But I digress!
Perhaps the largest difficulty component software has had to face
is the wide range of disparate microprocessors and operating systems
in use today. There have been a variety of reasonable attempts
at component software, but they've always been limited to a specific
operating system. Microsoft's VBX and OCX component architectures
have had great success in the pc world, but they've done little
to bridge the gap between other types of operating systems. Weighing
in the amount of work required to get an inherently platform-dependent
component technology running on a wide range of operating systems,
it makes sense that Microsoft has focused solely on the pc market.
| Note |
Actually, Microsoft's new ActiveX technology, which is based on its OCX technology, aims to provide an all-purpose component technology compatible across a wide range of platforms. However, considering the dependency of ActiveX on 32-bit Windows code, it has yet to be seen how Microsoft will solve the platform-dependency issue. Maybe they are just waiting around for everyone to switch to Windows 95/NT? |
Prior to the explosion of the Internet, the platform-dependency issue wasn't all that big a deal. pc developers didn't necessarily care too much that their products wouldn't run on a Solaris system. Okay, some pc developers hedged their bets and ported their applications to the Macintosh platform, but most with considerable development efforts. The whole scenario changed with the operating system melting pot created by the Internet. The result was a renewed interest in developing software that everyone can use, regardless of which operating system they happen to be running. Java has been a major factor in making truly platform-independent software development a reality. However, until recently Java has not provided an answer to the issue of component software-we'll get to that in just a moment.
As if the platform-dependency issue weren't enough, some existing component technologies also suffer from having to be developed in a particular programming language or for a particular development environment. Just as platform dependency cripples components at runtime, limiting component development to a particular programming language or development environment equally cripples components at the development end. Software developers want to be able to decide for themselves which language is the most appropriate for a particular task. Likewise, developers want to be able to select the development environment that best fits their needs, rather than being forced to use one based on the constraints of a component technology.
So any realistic long-term component technology must deal with both the issue of platform dependency and language dependency. This brings me to the topic at hand: Java Beans. JavaSoft's Java Beans technology is a component technology that answers both of these problems directly. 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 under development with a preliminary release to follow soon after.
Java Beans is being implemented as an architecture- and platform-independent 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.
Following the rapid success of the Java runtime system and programming language, JavaSoft realized the importance of developing a complete component technology solution. Its answer is the Java Beans technology, whose design goals can be summarized by the following list of requirements:
The first requirement of Java Beans-to be very compact-is based on the fact that the 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 with 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, since Java applets are already very efficient in terms of size.
The second major goal of Java Beans is to be fully portable; you learned the importance of this at the beginning of this lesson. 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 together comprise the platform-independent component solution alluded to earlier. As a result, developers will not need to worry about including platform-specific libraries with their Java applets. The result will be reusable components that will unify the world of computing under one happy, peaceful umbrella. OK, 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 where 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, which is the capability of 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. Alternately, developers can create customized
persistence solutions whenever necessary.
| New Term |
Persistence is the capability of an object or component to store and retrieve its internal state. |
| New Term |
Serialization is the process of storing or retrieving information through a standard protocol. |
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 as a result of 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, since distributed computing solutions inevitably require much more overhead.
Java Beans component developers have the option of selecting a distributed computing approach that best fits their needs. JavaSoft provides a distributed computing solution in its Remote Method Invocation (RMI) technology, 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 that 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 the way 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.
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 most objects will need to support, such as persistence and event handling.
The current Java component model, although not bad, is relatively limited when it comes 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 via 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.
| Note |
A nonvisual component is 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, which fires timing events at specified intervals. Timer components are very popular in other component development environments, such as Microsoft Visual Basic. |
You can use together a variety of Java Beans components without necessarily writing any code by using visual tools. 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, using 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.
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. So all the functionality provided by Java Beans is actually implemented in the Java Beans API. The Java Beans API itself is 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 today:
By understanding these services and how they work, you'll have much more insight into exactly what 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. The next few sections are devoted to each of these APIs and why they are necessary elements of the Java Beans architecture.
The GUI-merging APIs provide a means for a component to merge
its GUI elements with the container document, which is usually
just the Web page containing the component. Most container documents
have menus and toolbars that need to 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.
| New Term |
A container document is a document (typically HTML) containing Java Beans components that serves as a parent for all the components it contains. Container documents typically are responsible for managing the main menu and toolbar, among other things. |
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.
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.
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. This brings us to the high-level APIs. The high-level APIs use the low-level APIs to determine which parts of a component are exported for user modification. So although development tools will undoubtedly make use of both APIs, they will use the high-level APIs only when providing component information to the user.
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 is so standalone runtime components can be as compact as possible. In a purely runtime environment, components are transferred with only the necessary runtime component. Developers wanting to use the design-time component facilities can easily acquire the design-time portion of the component.
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 microprocessors in anything from net computers to pagers."
The status of the JavaOS project is still largely under wraps as of this writing, but there is enough information out to at least get an idea of where JavaSoft is headed with it. First and foremost, JavaOS is expected 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 on which it is built. The idea of building a complete operating system on top of the existing Java technology makes perfect sense. And if JavaSoft puts as much thought into JavaOS as it did into Java, it will no doubt be a very interesting operating system.
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 could benefit from a compact operating system and support for a powerful programming language like Java.
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 largely targeting 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.
| New Term |
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, since there is typically no other storage means beyond random access memory (RAM), which is temporary. |
| New Term |
An embedded system is a scaled-down computer system programmed to perform a particular function within an electronic device. |
JavaSoft has made mention of JavaOS being able to run with as little as 512KB of ROM and 256KB of RAM in an embedded environment. Likewise, an entire JavaOS system running on a networked computer requires only 3MB of ROM and 4MB 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.
Because of the success of Java, JavaOS is able to enjoy industry support prior to 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. |
As if Sun weren't branching out enough with JavaOS, it recently
surprised the microprocessor world by announcing the development
of a line of microprocessors that are 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. So whenever I refer to Sun I'm referring to the overall company. |
Java microprocessors are quite obviously yet another move on Sun's part to capitalize on the success of Java. However, like JavaOS, Sun legitimately has an interesting and potentially lucrative angle in developing Java microprocessors. Also like JavaOS, the primary target application for Java microprocessors is in embedded systems. Speed is a critical factor in embedded systems, primarily due to the limited horsepower available in such small systems. Java microprocessors have the potential to significantly increase performance since they are being designed around the highly efficient Java technology. Contrast this with other embedded microprocessors that typically have a more general design.
Sun is pushing Java microprocessors based on a new microprocessor product paradigm: simple, secure, and small. Add to this Sun's promise of delivering 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- and board-level products to support the microprocessors.
Even though the prospect of a Java microprocessor might seem strange
at first, it's not hard to see the 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?
| New Term |
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 electronic devices. |
The Java processor family is slated to consist of three lines of microprocessors:
The next few sections describe these different processor lines and which applications each is targeting.
The low-end line of Java microprocessors is called picoJAVA and serves as the basic design on which all the microprocessors are based. The picoJAVA core is designed to provide the best price/performance microprocessor that fully supports the Java virtual machine. The picoJAVA line of microprocessors is expected to have a per-processor cost of under $25, establishing it as a prime target for cellular phone applications, among many other consumer electronics products.
The next processor line above picoJAVA 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 network devices such as telecommunications equipment, along with other non-network applications such as printers and video games.
The high-end line of Java microprocessors is called UltraJAVA and is designed to be 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. With an expected cost starting at $100, the UltraJAVA processor line may still be a bargain.
Today you have taken stock of the future of Java by learning about some technologies that are built on the stable framework of Java. Although these technologies may not necessarily affect your Java development efforts anytime soon, they will still play a critical role in Java reaching maturity as a stable technology. You began the lesson by learning about Java Beans, which is a new software technology that promises to bring reusable software components to Java. You then moved on to JavaOS, which is a new operating system based entirely on the Java virtual machine. You finished up the lesson with a look at the new Java microprocessors, which aim to be first silicon Java implementation.
This lesson concludes your bonus week. Throughout this week you've learned a great deal of information that isn't entirely related, except for the fact that Java is at the heart of it all. I encourage you to use this information as a foundation to learn more about Java programming and the emerging technologies that will enhance it in the future.
| What is the difference between a Java Beans component and a regular Java class? | |
| A Java Beans component is a regular Java class built on the Java Beans API. More specifically, a Java Beans component adds to the standard Java class structure the ability to interact with other components, a well-defined mechanism for exposing information about itself, and a means by which it can be visually edited. | |
| What is an example of a container document? | |
| A good example of a container document is an HTML page. Understand that the role of a container document goes beyond just being a document in the sense that an HTML document consists of HTML code. In regard to Java Beans components, a container document provides much of the overhead of the parent application, such as managing the main menu and toolbar. In this case, the parent application is the Web browser the document is being viewed in. | |
| Will JavaOS compete with established desktop operating systems like Windows 95 or the Macintosh OS? | |
| I'm not going to make any absolute statements here, but it looks extremely unlikely that Sun would ever position JavaOS as an operating system that would compete in the personal computer market-or any desktop computer market, for that matter. By design, JavaOS is targeted toward more compact systems, such as those prevalent in consumer electronics products. | |
| Will JavaOS and Java microprocessors change the Java language in any way? | |
| No. The Java language is frozen as of version 1.02, meaning that any additions to the language must come in the form of new APIs rather than modifications to the core API. It is unlikely that either JavaOS or Java microprocessors would need to modify the design of the Java language, anyway. |