Java 1.1 Unleashed - 47 - Integrating Java and ActiveX by Michael Morrison IN THIS CHAPTER Technological Goals Under the Hood A Peaceful Coexistence Integrating Java and ActiveX With the full force of Microsoft behind it, it's no surprise that ActiveX has received tons of press attention lately. As an Internet developer, you probably have some degree of confusion about how ActiveX fits into the Internet landscape. More specifically, you may be worried about what impact ActiveX will have on Java. This chapter takes a close look at Java and ActiveX and where each fits in the world of Internet development. This chapter also discusses an ActiveX technology that enables the integration of Java and ActiveX. The goal of this chapter is to give you some perspective on the relationship between Java and ActiveX. In doing so, you learn the details surrounding what each technology offers and why they don't necessarily have to be viewed as direct competitors. You also learn about a specific technology that aims to allow Java and ActiveX to happily coexist. Technological Goals In a general sense, Java and ActiveX both try to achieve the same goal: to bring interactivity to the Web. Because this is a very general goal, you probably realize that many different approaches can be taken to reach it. Java and ActiveX definitely take different routes to delivering interactivity to the Web, and for good reason; they're widely divergent technologies that come from two unique companies. Let's take a look at each technology and see what it accomplishes in its pursuit to liven up the Web. The Java Vision First and foremost, Java is a programming language. It certainly is other things as well, but the underlying strength of the Java technology is the structure and design of the Java language itself. The architects at Sun wanted to take many of the powerful features in C++ and build a tighter, easier-to-use, and more secure object-oriented language. They succeeded in a big way: Java is indeed a very clean, easy-to-use language with lots of advanced security features. The time spent designing the Java language is paying off well for Sun, because the language's structure is the primary cause of the C++ programmer migration to Java. However, the Java language without its standard class libraries and Internet support would be nothing more than competition for C++. In fact, the Java language, as cool as it is, would probably fail in a head-to-head match up with C++ strictly from a language perspective. This is because C++ is firmly established in the professional development community, and programmers need a very compelling reason to learn an entirely new language. Sun realized this and was smart enough to present Java as much more than just another programming language. The basic Java technology consists of the Java language, the Java class libraries, the Java runtime system, and the JavaScript scripting language. It's the combination of all these parts that makes the Java technology so exciting. Java is the first large-scale effort at creating a truly cross- platform programming language with lots of functionality from the start. Couple the slick language and cross-platform aspects of Java with its ability to seamlessly integrate Java programs into the Web environment and you can easily see its appeal. This integration of the Web into the Java technology is no accident; Sun simply saw the potential to capitalize on a technology they had been developing for a while by fitting it to the rapidly growing needs of the Internet. This pretty much sums up the primary aim of Java: to provide a way to safely integrate cross-platform interactive applications into the Web environment using an object-oriented language. Keep in mind, however, that new innovations such as JavaBeans, JavaOS, and Java microprocessors are rapidly altering and expanding Sun's vision of the Java technology. The ActiveX Vision Microsoft has different ideas for the Internet than Sun does. Unlike Sun, Microsoft initially didn't realize the immediate potential of the Internet, or at least didn't see how fast it was all happening. In fact, it wasn't until the excitement surrounding Java had begun to peak that Microsoft finally decided it had to rethink things in regard to the Internet and the Web. The connection was finally made somewhere in Redmond that the Internet would significantly affect personal computing. The company couldn't just sit idly by and see what happened; it could either take action to capitalize on the Internet or get burnt by not accepting it as a major shift in the way we all use computers. When Microsoft finally came to terms with the fact that the Internet was rapidly changing the face of computing--even personal computing--the company quickly regrouped and decided to figure out a way to get a piece of the Internet action. Keep in mind that Microsoft has never been content with just a piece of the action; it wants the largest piece of the action! Unlike Sun, Microsoft already had a wide range of successful commercial software technologies; it just had to figure out which one of them would scale best to the Internet. It turned out that one of the company's most successful technologies was ideally suited for the Internet: OLE (Object Linking and Embedding). Microsoft saw OLE as a powerful, stable technology with lots of potential for the Internet, and it was right; ActiveX is basically OLE revamped for the Internet. Unlike Java, however, ActiveX isn't just meant to be a way to add interactivity to the Web. Sure, that's part of it, but Microsoft isn't the type of company to just hand out technologies for the good of humanity. OLE is a technology deeply ingrained in most of Microsoft's commercial products, as well as many other commercial Windows applications. By simply migrating OLE to the Internet (through ActiveX), Microsoft effectively assumes a huge market share of Internet products overnight. Suddenly, every piece of code written based on OLE can now be considered ActiveX-enabled with little extra work. Microsoft's new goal of migrating desktop software to the Internet suddenly looks quite attainable. Although Microsoft is certainly looking to bring interactive applications to the Web with ActiveX, it is also looking to make sure that many of those interactive applications are Microsoft applications. This situation also ensures that Windows remains a strong presence on the Internet because OLE is essentially a Windows-derived technology. Although strategically ideal, the selection of OLE as the technological underpinnings for ActiveX has much more to do with the fact that OLE is a slick technology already tweaked for distributed computing; it's just the icing on the cake that OLE is already firmly established in the PC software community. Microsoft isn't the only company to benefit from the positioning of ActiveX. Every PC software developer that uses OLE in its applications will benefit from ActiveX just as easily as Microsoft. Because the PC development community is by far the largest in the industry, end users also benefit greatly because many software companies will be building ActiveX applications from existing OLE code that is already stable. In the discussion of ActiveX thus far, little has been said about programming languages. Unlike Java, ActiveX has nothing to do with a specific programming language; you can write ActiveX code in any language you choose that supports Microsoft's COM specification. Just in case you don't realize it, this is a big deal! Although Java is a very cool language, many programmers don't like being forced to learn a new language just to exploit the capabilities of the Internet. On the other hand, writing ActiveX controls in C++ is a little messier than writing Java applets in Java. Under the Hood Okay, so you have an idea about what each technology is trying to accomplish--but what does each actually deliver? It turns out that Java and ActiveX are surprisingly different in their implementations, especially considering how similar their ultimate goals are. Under Java's Hood The Java technology can be divided into five major components: The Java language The Java class libraries The Java runtime system The JavaScript scripting language The JavaBeans component technology The Java language provides the programmatic underpinnings that make the whole Java system possible. It is the Java language that shines the brightest when you compare Java and ActiveX. The Java class libraries, which go hand in hand with the language, provide a wide array of features guaranteed to work on any platform. This is a huge advantage Java has over almost every other programming language in existence. Never before has a tight, powerful language been delivered that offers a rich set of standard classes in a cross-platform manner. The Java runtime system is the component of Java that gets the least press attention, but ultimately makes many of Java's features a reality. The Java runtime system includes a virtual machine, which stands between Java bytecode programs and the specific processor inside a computer system. It is the responsibility of the virtual machine to translate platform- independent bytecodes to platform-specific native machine code. In doing so, the virtual machine provides the mechanism that makes Java platform-independent. Unfortunately, the virtual machine is also responsible for the performance problems associated with Java. These problems have been, and will continue to be, improved on thanks to just-in-time Java compilers and other related technologies. The JavaScript scripting language is the Java component that allows you to embed scripted Java programs directly into HTML code. The primary purpose of JavaScript is to allow Web developers who aren't necessarily programmers to add interactivity to their Web pages in a straightforward manner. The JavaBeans component technology is Java's way of providing a reusable, component-based software API. The JavaBeans technology allows developers to build applications from prebuilt software components that can easily be integrated in visual application builder tools. JavaBeans represents a significant step forward for Java because it helps solidify Java's status as a modern and elegant development language. Under ActiveX's Hood The ActiveX technology can be divided into the following major components: ActiveX controls ActiveX scripting (VBScript) ActiveX documents ActiveX server-side scripting (ISAPI) ActiveX controls are self-contained executable software components that can be embedded within a Web page or a standalone application. Acting as an extension to OLE controls, ActiveX controls can be employed to perform a wide range of functions, both with and without specific support for the Internet. ActiveX controls are essentially Microsoft's answer to Java applets, although ActiveX controls are significantly more open-ended than Java applets. In the same sense, JavaBeans is Sun's answer to ActiveX controls. ActiveX controls and JavaBeans components are designed to address the same need: a component software solution extensible enough to be used on the Web. Where ActiveX controls are Microsoft's answer to Java applets, VBScript is Microsoft's answer to JavaScript. Built on the highly successful Visual Basic programming language, VBScript provides much of the same functionality as JavaScript, but in an environment already familiar to many PC developers. ActiveX documents are similar to ActiveX controls, except that they are focused on the representation and manipulation of a particular data format, such as a Word document or an Excel spreadsheet. There is no logical equivalent in Java to ActiveX documents; ActiveX documents are a piece of the ActiveX technology that is completely foreign to Java. The final component of ActiveX is the ISAPI scripting language and server support. ISAPI provides a more powerful answer to CGI scripting, which has long been used to provide pseudo-interactivity for Web pages. ISAPI even goes a step further by providing a way to build filters into Web servers. Java servlets will eventually provide a similar functionality as ISAPI scripting. A Peaceful Coexistence Even though Java and ActiveX are perceived as competing technologies in a lot of ways, understand that I don't necessarily see Java and ActiveX as an either/or proposition. The software development community is far too diverse to say that one technology surpasses another in every possible way. In addition, consider that both of these technologies are in a constant state of flux, with new announcements and releases popping up weekly. In my opinion, it's foolish to think that a single software technology will take the Internet by storm and eliminate all others. Java will naturally find its way to where it is best suited, as will ActiveX. Likewise, smart software developers will keep up with both technologies and learn to apply each in cases where the benefits of one outweigh the other. And in case you're getting nervous about having to learn two completely new types of programming, here's some reassuring news: Microsoft has a technology that allows developers to integrate Java applets with ActiveX controls. What does that mean? Well, because ActiveX is language independent, it means you can write ActiveX controls in Java. Furthermore, it means you can access ActiveX controls from Java applets and vice versa. To me, this is a very exciting prospect: the ability to mix two extremely powerful yet seemingly divergent technologies as you see fit. The technology I'm talking about is an ActiveX control that acts as a Java virtual machine. What is a Java virtual machine? A Java virtual machine is basically a Java interpreter, which means that it is ultimately responsible for how Java programs are executed. By implementing a Java virtual machine in an ActiveX control, Microsoft has effectively integrated Java into the ActiveX environment. This integration goes well beyond just being able to execute Java applets as if they were ActiveX controls; it provides a way for ActiveX controls and Java applets to interact with each other. It also provides a way of using JavaBeans components as if they were ActiveX controls. Microsoft's willingness to embrace Java as a way to develop ActiveX objects should give you a clue about the uniqueness of each technology. It could well end up that Java emerges as the dominant programming language for the Internet, while ActiveX emerges as the distributed interactive application standard. I know this seems like a confusing situation, but it does capitalize on the strengths of both Java and ActiveX. On the other hand, JavaBeans could emerge as a serious contender on the component front and give ActiveX some competition. Fortunately, both Microsoft and Sun are showing some degree of interest in supporting each other's technologies. Microsoft has a variety of different Java efforts under way, including a highly optimized Java VM, a native Java compiler, and a Windows-specific Java API, among other things. Similarly, Sun has expressed a great deal of interest in ensuring that JavaBeans components can be successfully integrated with ActiveX. The main point is that ActiveX and Java are both strong in different ways, which puts them on a collision course of sorts. The software development community is pretty objective; if programmers can have the best of both worlds by integrating ActiveX and Java, then why not do it? No doubt both Sun and Microsoft will have a lot to say about this prospect in the near future. The ActiveX Java virtual machine is a major step in the right direction. Integrating Java and ActiveX As you just learned, the ActiveX Java virtual machine (VM) control allows Java programs to run within the context of an ActiveX control. What does this really mean from the perspective of a developer wanting to mix Java and ActiveX? It means you can treat a Java class just like an ActiveX control and interact with it from other ActiveX controls. In other words, the Java VM control gives a Java class the component capabilities of an ActiveX control. You now understand that Java classes and ActiveX controls can interact with each other through the Java VM control, but you're probably still curious about the specifics. One of the most important issues surrounding Java's integration with ActiveX is the underlying Component Object Model (COM) protocol used by ActiveX. COM is a component software protocol that is the basis for ActiveX. The importance it has in regard to Java is that Java's integration with ActiveX really has more to do with COM rather than the specifics of ActiveX. So, when I refer to Java integrating with ActiveX, understand that the COM protocol is really what is making things happen under the hood. This brings us to the different scenarios under which Java and ActiveX can coexist. Keep in mind that some of these scenarios require not only the Java VM control at runtime but also support for Java/ActiveX integration at development time. In other words, you may have to use a development tool that supports Java/ActiveX integration, such as Microsoft Visual J++. Following is a list of the different situations possible when integrating Java and ActiveX using the Java VM control: Using an ActiveX control as a Java class Using JavaBeans or a Java class as an ActiveX control Manipulating a Java applet through ActiveX scripting Using an ActiveX Control as a Java Class It is possible to use an ActiveX control just as you would a Java class in Java source code. To do this, you must create a Java class that wraps the ActiveX control and then import the class just as you would any other Java class defined in another package. The end result is that an ActiveX control appears just like a Java class at the source code level. Because we are talking about Java source code here, the Java compiler has to play a role in making this arrangement work. This approach requires support for Java/ActiveX integration in the Java compiler. The Visual J++ Java compiler includes this exact support. Visual J++ includes a tool that automatically generates Java wrapper classes for ActiveX controls. You can then import these wrapper classes into your Java code and use them just like any other Java class. Of course, behind the scenes, the ActiveX control is actually doing all the work, but from a strictly programming perspective, the Java wrapper class is all you have to be concerned with. Using a Java Class or a JavaBean as an ActiveX Control Just as you can use an ActiveX control as a Java class, you can also use a Java class as an ActiveX control. Because ActiveX controls are manipulated through interfaces, you have to design Java classes a little differently so that they fit into the ActiveX framework. You must first define an interface or a set of interfaces for the class, using the Object Description Language (ODL) that is part of COM. You then implement these interfaces in a Java class. Finally, you assign the Java class a global class identifier and register it as an ActiveX control using a registration tool such as JavaReg, which ships with Visual J++. I know this procedure is a little messier than simply compiling a Java class, but consider what you are gaining by taking these extra steps. You are using one set of source code and just one executable to act as both a Java object and an ActiveX control, with relatively little work. Users can then take advantage of all the benefits of component software by using your Java class as an ActiveX control. Although no ActiveX environments supporting JavaBeans have been released as of this writing, it is expected that JavaBeans components will fit into ActiveX much more smoothly than other Java classes do. We have this expectation because JavaBeans components already have well-defined interfaces, which is a formal requirement of ActiveX. Additionally, Sun is working toward specifically ensuring that JavaBeans is in some way compatible with ActiveX. Manipulating a Java Applet through ActiveX Scripting Another less obvious scenario involving Java and ActiveX is the ability to manipulate Java applets through ActiveX scripting code. The ActiveX scripting protocol, which supports both VBScript and JavaScript, allows you access to all public methods and member variables defined in a Java applet or JavaBeans component. The ActiveX protocol is specifically designed to expose the public methods and member variables for Applet-derived classes, so any other classes to which you want scripting access must be manipulated indirectly through public methods in the applet. You learn the specifics of using VBScript to control Java applets in Chapter 48, "Using Java with VBScript." Summary This chapter took an objective look at Java and ActiveX and where they fit in the quest to make the Web interactive. You learned not only about the philosophy and reasoning behind each technology, but also why the technologies don't necessarily have to be considered competition for each other. You finished up the chapter by learning about Microsoft's plans to integrate Java and ActiveX. This combination of two powerful technologies, although a little confusing at first, is crucial for Web developers because it lessens the need to pick one technology over the other. Possibly the biggest benefit is the peace of mind in knowing that you can continue working with Java without fear that Microsoft and ActiveX will erode your efforts. This chapter also touched on your ability to use VBScript to control Java applets. The next chapter gives the details about how VBScript works and what benefits it offers.

©Copyright, Macmillan Computer Publishing. All rights reserved.