by Bryan Morgan
Visual J++ is the name of Microsoft's first Java development tool. It was originally internally dubbed Jakarta after the largest city on the island of Java, but Microsoft refrained from using yet another coffee- or Java-related name for this product. The name Visual J++ can be taken to mean several different things:
At its most basic level of operation, Visual J++ provides a high-performance Java compiler, integrated development environment (with a resource editor, visual debugger, and visual editor), programming wizards, and extensive online help capabilities. Standard Java applets and applications built using the Microsoft Visual J++ tool set will run unmodified on any machine on earth that includes a copy of the Java Virtual Machine (more on this later).
Had Microsoft stopped at that point and released a tool with these capabilities, Visual J++ would be highly regarded for its excellent development environment and extremely fast compiler. Visual J++ uses the Developer Studio environment, which also is used by the Visual C++ and Fortran Powerstation products. The compiler can compile up to one million lines of Java code per second (on a standard Pentium-based computer), which should place it near the top of the heap in compilation speed. As stated earlier, had Microsoft stopped with these features, this chapter would focus primarily on the Java language and its use in the development of applets and applications (a topic that has produced over 100 books in Java's first year alone!).
However, as you probably know by now, Visual J++ is much more
than a standard Java compiler. Microsoft has worked for several
years to produce an object-based framework for the Windows platform
with the eventual goal of making this framework distributed
and cross-platform.
| NOTE |
The term distributed here means that objects can be shared across multiple computers. In other words, if an application were running on your local machine, it could call into objects running on machines elsewhere across the network. This enables applications to be partitioned across multiple machines for performance reasons, and improves maintenance because only one machine needs to be updated in the case of software updates. The term cross-platform is used in this chapter to represent computers sharing information or programs even when the computers are running different operating systems. An example of a cross-platform environment is a network of Windows 95 and Apple Macintosh computers using programming objects stored on a UNIX server. |
Microsoft's object standard is known as the Component Object Model (COM), and the implementation of this standard is personified in a group of technologies known as ActiveX. One ActiveX technology that will be familiar to Windows developers is ActiveX controls. These components (formerly known as OCX, or OLE, controls) are industry standard programming tools now used by many, if not most, Windows programmers. A partial list of products that support the use of ActiveX controls is as follows: MS Visual C++/Visual FoxPro/Visual Basic/Access, Borland C++/Delphi, Powersoft Powerbuilder, and Oracle PowerObjects.
Why is ActiveX being discussed in a section about a Java compiler? This is what separates Visual J++ from every other Java tool on the market! The Visual J++ tool set, in combination with the Microsoft Windows Virtual Machine for Java, will enable Java programmers to use ActiveX controls along with Java applets. In addition, standard Windows applications can be built using Visual J++, ActiveX, and the underlying COM. This will enable Windows developers to utilize the full power and elegance of the Java language along with the huge existing base of COM objects in which many developers already have invested.
What does this mean for Windows and Java programmers? First of all, it means now that these two can be one and the same. Just as there are Windows VB developers and Windows C++ developers, new projects will soon be able to choose Java as a development choice. In short, Microsoft is elevating Java from its already lofty status as a Web programming tool to that of THE Web programming tool and also a Windows programming tool. Actually, in the near future it might become inaccurate to refer to Visual J++ as simply a "Windows tool" because COM is gradually becoming a cross-platform object model (more on this later).
Had Microsoft chosen to simply make Visual J++ a graphical layer over the standard Java tools, the Visual J++ programmer could use Java to do the following:
With the extra capabilities that Microsoft has added to Visual J++, the Visual J++ programmer is able to
As you can see, the first three items in this list are possible using virtually any Java tool on the market today. Despite many Java programmers' fears that Microsoft would release a proprietary tool that would somehow pollute the Java waters, these fears are unfounded. A key point is that Visual J++ is a great tool to use for non-ActiveX and ActiveX Java development. After all, despite the explosive growth and potential of the World Wide Web, it will be quite some time before the majority of applications developed are designed to run only within a Web browser.
The Java language has grown faster than any other programming language in the history of computing. Because nearly all of the Java demonstrations and press coverage of Java have focused on its use as a World Wide Web development tool, many developers might not realize that Java can be used to write stand-alone applications with advanced graphical user interfaces. Because Microsoft Windows is the most widely used operating system in the world today, and because of the vast amount of existing code already written for the Windows platform, an ideal software development tool would enable the Java developer to combine the best of the Web world with the best of the Windows world. For many developers, Visual J++ will be that tool.
Although Visual J++ will obviously be used by many for the development of standard Java applets for Web distribution, Microsoft must be credited for realizing that the Java language itself is a great programming language. Because of the features of the Java language and the impetus behind it, Microsoft extended Visual J++ and the Windows Virtual Machine for Java to enable Java applications to incorporate existing ActiveX controls. Using Visual J++, ActiveX controls and Java classes are identical to the Java programmer. This is possible because of the Microsoft Java Virtual Machine and the underlying similarities between Java and Microsoft's Component Object Model. The following section discusses the evolution of COM and ActiveX and concludes by showing how the Java language and COM fit together nicely. The chapter then concludes with a discussion of the benefits and weaknesses of Java and ActiveX.
The next chapter focuses on using Visual J++ to develop full-featured Windows applications using Microsoft's ActiveX technologies. Many developers might wonder: Exactly what is ActiveX and where did it come from? Although it was announced by Microsoft in 1996, believe it or not, it has actually been around for several years and nearly all Windows developers have used some form of it at one time. Before diving into ActiveX, however, the history of the Component Object Model (COM) and Object Linking and Embedding (OLE) are examined.
COM provides the basis for nearly all of Microsoft's new products.
It is, in theory, a platform-independent, vendor-independent,
and language-independent model for developing applications using
intercommunication among binary objects. These objects communicate
with each other using a set of predefined interfaces that each
object chooses to implement.
| NOTE |
An interface is a set of related functions that can be implemented by an object. If an object chooses to implement an interface, all of the functions specified by that interface must be implemented. |
Each object is defined by which interfaces it chooses to implement. (For example, if a developer wanted an object to be saved to disk, he or she could implement what is known as a structured storage interface.)
Note that the words in theory are used in the previous paragraph to describe the COM standard's cross-platform capabilities. Although a COM infrastructure could be written for any operating system, the fact remains that at the present time it is available only for the Windows family of operating systems. Microsoft recently has announced plans to assist Metrowerks in porting COM to the Apple Macintosh and currently is working with Bristol and MainSoft to port COM to UNIX. However, at the current time, developers should realize that using COM objects in an application will limit the platforms on which that application will run. This possible drawback is discussed later in the "Advantages and Disadvantages: A Close Look at Java and ActiveX" section.
COM is both a specification and an actual implementation. The COM specification specifies a binary standard for implementing the object, which is language-independent. Therefore, a COM object could be written using Delphi, Visual Basic, C++, or-you guessed it-Java. All that is required is that a specific set of functions be provided by your object so that the object's provided interfaces can be queried.
The COM implementation is provided in the form of a Windows dynamic link library (DLL). This DLL exports a small number of API functions that enable the programmer to instantiate a component object using a unique class identifier known as a Class ID. What is important to realize is that COM, by itself, simply provides the "rules" for which objects can be instantiated and can intercommunicate among themselves. All of these objects can be combined to make an application. With the advent of Distributed COM (DCOM), these objects can be located anywhere across a network. This functionality is a core part of Windows NT 4.0.
Although COM is destined to be an integral part of future Microsoft operating systems, COM has never been an active topic of discussion among most Windows developers. This is because COM, by itself, does not specify any applicable, real-world objects that can be used by developers to create applications. Instead, COM is the object model that developers can use to integrate several objects into a working application. These objects could come from a variety of sources. Here are some examples:
Although it is completely possible to write from scratch COM objects that are fully compliant with the binary specification, most Windows developers have never done this. Instead, programmers who want the functionality provided by the COM object model have historically relied on a framework that lies on top of COM known as OLE. OLE stands for Object Linking and Embedding and is the parent of what is now known as ActiveX.
As the name implies, Object Linking and Embedding was originally a technology used by Microsoft to link together desktop application products. This was provided so that users could do things such as insert a Microsoft Excel spreadsheet into a Microsoft Word document. As the user scrolls through the Word document and comes upon the Excel spreadsheet, he or she could double-click the Microsoft Excel icon to launch a copy of Excel and view or edit the spreadsheet.
Although the OLE standard at this point was much simpler than what exists today, it still enabled inter-application communication and data exchange. After OLE 1.0 was developed, the methodology was well-documented and supported by Microsoft, and soon many applications appeared that enabled their application objects to be integrated together. In a short time, OLE became the standard way for applications to interoperate. Because of OLE1's success, Microsoft realized it could provide the foundation for a more generic object framework that gave the user and developer many more capabilities. At the same time, Microsoft began to aggressively position itself as an enterprise system provider using Windows NT as a network server and products such as SQL Server for database operations. In the Microsoft scheme of things, all desktop machines would be running some variant of the Windows operating system. These machines would be able to communicate among each other using a Windows NT-controlled network and could share information using products such as SQL Server and Exchange. In such a networked environment, DCOM would enable applications (or even operating systems!) to be distributed across the network for scalability and administration reasons.
As Microsoft's rapid growth in this area coincided with the development of OLE 2.0, this release of OLE became much more than a mechanism for combining documents.
OLE 2.0 was released in 1993, and some improvements were immediately visible. OLE 2.0 applications not only could embed documents created by other applications, but these documents could also be edited and updated directly within the "container" document.
If the user were to edit a Microsoft Word document that contained a chart, the application would appear to be Microsoft Word. However, if the user double-clicked the chart, OLE 2.0 enabled the application to essentially "morph" into Microsoft Excel (see Figure 9.1). The user then could operate on the chart using the Excel menus and options, and immediately switch back to the word processing functionality provided by Word after the chart had been edited.
Figure 9.1 : An example of OLE 2.0 in-place activation.
This capability was termed in-place activation and notified the world that OLE 2.0 was truly ready for prime time. After programmers took the time to analyze the OLE 2.0 specification, it became apparent that OLE2 was in fact a large set of advanced features that offered programmers capabilities that, in the past, would have been impossible to implement. Figure 9.2 illustrates the features provided by OLE2 and the following section explains each of these features briefly.
Figure 9.2 : OLE 2.0 features.
OLE 2.0 is basically a large grouping of COM-compliant objects that can be conveniently grouped into several primary categories:
Each of these categories relies on the underlying Component Object Model to specify how the objects interoperate with each other.
Compound Documents
The portion of OLE2 known as compound documents concerns itself with the linking and embedding of objects. To fully understand what a compound document is, you must first understand what it means to "link" and "embed" objects.
Objects are linked when the following steps occur:Objects are embedded when an object created by one application is visually and physically part of a file created and displayed by another application instance. Figure 9.1 shows an example of embedding.
- A portion or all of a file's contents created by Application1 is inserted into a file created by Application2.
- The portion of Application1's file is designated as a link within Application2.
- When Application1's file is modified, these changes become apparent when you are viewing Application2's file.
To give you an idea of the amount of progress made between OLE1 and OLE2, OLE1 essentially consisted of two subsets of compound documents: linking and embedding. Obviously, OLE2 was a huge leap forward! You can think of an OLE2 compound document as providing three possible features:
Uniform Data Transfer
All data transfers that occur among OLE2 objects use the technology known as Uniform Data Transfer. This capability provides the definition of something known as a data object. A data object is a single piece of code that can be used in all data transfers: DDE, OLE, drag-and-drop, and Clipboard transfers. Note that this data transfer does not necessarily take place through memory. OLE2 enables the programmer to perform data transfer using files, memory, or any other methodology that the programmer chooses. Once again, looking into the future, one can envision transfer methods such as FTP or HTTP for extending what we now think of as OLE2.
Drag-and-Drop
In most GUI environments such as Macintosh, Motif, or Windows, users have had the capability to drag and drop items within applications or from File Manager-type applications. OLE2 takes this functionality a step further by enabling any data object from any application to be dragged and dropped into any other OLE2 application that supports this feature. Essentially, any data object that can be copied to the Windows clipboard can be used with drag and drop.
Compound Files
You can think of compound files as files within files. Programmers building files using OLE2 compound files can literally create directory trees within files for storing different types of data. Compound files also can contain data created by several different applications. Because compound files are composed of a tree-like structure, you can query compound files for information such as author, modification date, and other features. An example of a compound file that is an integral part of all Windows systems now is the Windows Registry. Under Windows 95, you can examine the Registry by running REGEDIT.EXE. Under Windows NT, this file is called REGEDT32.EXE.
Monikers
Monikers are used to provide links between objects on a system (or across a distributed system). A moniker is another word for a nickname, and you can think of OLE2 monikers as a type of nickname. Monikers are basically nicknames that identify the source of data and understand how to bind an application to that data. There are many different types of monikers in OLE2, including File, Pointer, and Item monikers.
OLE Controls
OLE Controls, or OCX Controls as they are often called, carry on the spirit of the VBX controls introduced with Visual Basic 3.0. Unlike VBX controls, which are special-case 16-bit DLLs, OLE Controls can be 32-bit controls that implement a standard set of OLE2 interfaces. The result is a programming object that can be used at design-time (in a development environment such as Visual Basic or Delphi) and at runtime within an application. These controls are language-independent and have been extremely successful. At the present time, over 1,000 OLE Controls are commercially available.
Automation
OLE Automation is a technology that is included within the OLE2 umbrella. However, in many ways it is much larger than OLE2. An application can support OLE Automation by exposing its desired functionality through a set of interfaces. These interfaces can then be used to manipulate (automate) the application by another piece of code. Visual Basic is commonly used to control Microsoft Office applications through the use of OLE Automation. (In fact, there are whole books written on that topic alone!) Through the process of OLE Automation, programmers can choose the language and tool they would like to use to control other programmable objects. OLE Automation is included in most discussions of OLE2 because it uses the underlying Component Object Model as a blueprint for inter-object communication.
All of these technologies represent a huge investment for Microsoft. Thousands of hours and millions of dollars have been spent to build an object framework for the Windows platforms. With the advent of DCOM in the very near future, Microsoft is positioned to finally compete and interoperate with other popular object models such as Distributed Computing Environment (DCE) and Component Object Request Broker Architecture (CORBA). From Microsoft's point of view, it is clear that technologies such as the World Wide Web and Java can be used to interoperate with their existing code infrastructure. To do this, Microsoft has introduced a trimmed-down version of OLE2 known as ActiveX to truly activate the Internet.
The wary reader might by this point be wondering where this discussion is headed. After all, on one hand you have learned the Web and Java's use in building networked, platform-independent applications. On the other hand, you have learned OLE and its capabilities for building object-based applications on the Windows platform. Now the two technologies will be brought together using the magic of COM and Windows Virtual Machine for Java.
In 1995, all Microsoft projects were issued a well-publicized edict to Internet-enable every product if possible. The results of that request are beginning to be seen nearly a year later as Microsoft is releasing a flood of products aimed at corporate and independent Web developers. (Visual J++ is one of the products leading this charge.) While OLE2 was introduced to address the needs of desktop software developers and system integrators, in the previous section you learned many topics that could clearly be applied to networked applications. Like all other Microsoft products, OLE2 was thoroughly examined from an Internet point of view and the resulting set of transformed technologies has been named ActiveX. Many pieces of OLE2 have been completely reworked for maximum performance benefits for Web usage, while other technologies basically have been renamed and remarketed as ActiveX technologies.
Like its parent, OLE2, ActiveX cannot be summed up as one simple technology. Instead, it can be broken into several parts, all of which can be thought of collectively as Microsoft's ActiveX architecture. The following highlights the key ActiveX technologies and draws a parallel between them and their parent OLE2 technologies.
ActiveX is the name of a group of related technologies from Microsoft that is designed to enable developers to provide active Web content. Although at the current time ActiveX is a Windows-only technology, implementations for the Macintosh and UNIX operating systems are slated for release in the near future. When this platform independence is a reality, ActiveX will enable software developers to choose their language and tools, reuse existing inventories of objects, and develop extremely powerful distributed applications for use on a variety of operating platforms. It will do this using a variety of technologies that exist under the ActiveX umbrella, including
ActiveX Documents
ActiveX documents can be thought of as Internet-aware OLE2 compound documents. An ActiveX-enabled Web browser such as Microsoft Internet Explorer can download a Word document from a Web browser and immediately know how to display that file through the use of ActiveX documents. This technology continues Microsoft's information-centric approach, which enables users to concentrate more on an application's content than on the application itself.
ActiveX Controls
ActiveX controls are extensions of the OLE controls mentioned earlier in this chapter. In fact, in many instances there is no difference at all between an ActiveX control and an OLE control. Microsoft simply reduced the number of interfaces that an ActiveX control is required to implement. Potentially, this enables ActiveX controls to be much smaller than their OLE counterparts. However, in many situations the same interfaces will be required to be implemented.
ActiveX Scripting
ActiveX scripting extends the concept formerly known as OLE Automation by adding scripting capabilities to Web pages, programs, or even server applications. ActiveX scripting enables scripts to be written in a variety of languages because it uses two components: a scripting host and a scripting engine. The scripting host is an application that is responsible for creating the scripting engine. The scripting engine in turn is responsible for processing and performing the script commands. Examples of scripting hosts include
Scripting engines are currently available for Visual Basic for Applications (VBA), Visual Basic Scripting Edition (VBScript), and JavaScript.
ActiveX-Enabled Internet Protocols
Common Internet protocols such as FTP and HTTP can use ActiveX technologies such as monikers (equivalent to an OLE moniker). These monikers can serve as pointers to applications and can be interpreted by ActiveX server products in order to link applications to the Internet.
ActiveX APIs
An entire suite of ActiveX APIs is available through the ActiveX Software Development Kit (SDK). These APIs enable software developers to extend traditional Windows-based programs with Internet capabilities such as file transfer and Web server access.
Microsoft Windows Virtual Machine for Java
The final component of ActiveX that you will learn is the Microsoft Windows Virtual Machine for Java. This Java Virtual Machine is designed to both run standard Java applets and also expose Java applets as COM objects for their use in ActiveX applications. The Windows Virtual Machine for Java also enables Java applets to coexist with ActiveX controls because to the programmer, both are just objects composed of properties, methods, and events.
Visual J++ is the first product to combine two extremely popular technologies: Java and COM. This is possible because the two are extremely similar on many levels. This section summarizes the capabilities of Java and COM and discusses why they fit together very well.
From the outset, it is obvious that in some ways Java and COM are very different technologies. Most notably, Java is a programming language, and COM is an object model that specifies how objects created in any programming language must interact. However, it is fair to say that Java objects and COM objects can be compared and contrasted.
Java objects are not distributed. Although it is true that Java objects can be stored on remote servers, these objects must actually be uploaded to the client machine before they can be used to run an applet within a browser. Meanwhile, DCOM objects can be stored on a remote machine and can be called from that remote machine using a Remote Procedure Call (RPC).
Java applets are designed with specific security restrictions. These restrictions include the incapability to call code on any server other than the originating server and the incapability to make local operating system calls. COM objects have full access to the underlying operating system and rely on a completely different security model that revolves around a concept known as code signing.
Java classes are not required to implement interfaces (groups of related functions that can be thought of as a unit). The Java programmer can choose to implement zero or more interfaces for each Java class. COM objects are required to implement at least one interface: IUnknown. This interface then is used to determine specific information about the object and to acquire new interfaces if necessary.
Java also uses a technique known as garbage collection for automatic memory management. When the system knows that an object is not going to be used any longer, the Java runtime system automatically frees that object's memory. Memory management with COM produces an equivalent result to produce automatic memory management. Instead of garbage collection, however, COM tracks the reference count, or the number of instances using an object. When the reference count drops to zero, that object is freed in memory.
Despite the differences mentioned in the previous section, the number of similarities between Java and COM is very interesting (and an excellent sign that both technologies benefit from a good design!). This is probably not surprising if one stops to really think about what both Java and COM were designed to solve. They both were intended to be
To start with, Java and COM both require a foundation underneath them to support their platform-independent claims. Java's foundation is known as the Java Virtual Machine, whereas COM requires an implementation of the Component Object Model for each specific platform. After this foundation is in place, both systems rely on objects that are created on the fly and are dynamically linked together at runtime.
Even the way that the objects are defined is similar in some respects. Java uses a .class file format that is well-documented. The class file defines the contents of the internal class and any interfaces it implements. COM uses a .tlb (type library) file to define the contents of the COM object and any interfaces it implements. A key factor in the operation of the Windows Virtual Machine is its capability to create type libraries from Java classes and likewise create Java classes from COM object's type libraries.
As you might have noticed by now, both rely heavily on the use of interfaces. Interfaces enable objects to implement a related set of functions for an object. The intent of these interfaces is generally documented, therefore the interface serves as a sort of contract between one object (the implementor of the interface) and another (the user of the interface). Java and COM both use classes (a concept familiar to object-oriented programmers) to group together related functions and data.
One feature of many systems and languages is exception handling. Exception handling enables the developer to trap errors and handle them accordingly so that the program will not simply crash. Java handles exceptions through the use of the Throwable interface. COM handles exceptions through the use of the IErrorInfo interface.
Because of the excitement surrounding Java since its introduction in 1995, the software development community has enthusiastically supported Java and pushed it to the forefront of Web development. However, like all new technologies, it has some advantages as well as disadvantages. ActiveX is no different than Java in this respect. You learn these strengths and weaknesses here so that you are well aware that no technology by itself can solve every problem out there. As with all complicated undertakings, a variety of issues need to be weighed before decisions are made.
Java's greatest advantage might be that it is the most powerful,
ubiquitous programming language that enables developers to create
platform-independent code. Unlike most other cross-platform tools,
the Java developer actually has to make an effort in order to
add platform-dependent code to the application at hand. Java programmers
can thank the availability of the Java Virtual Machine for this
feature.
| NOTE |
Although it is true that Java is not truly platform-independent without the availability of a Java Virtual Machine, the fact is that the JVM is available now (or will be soon) on nearly every popular operating system in widespread use today. |
Java is also object-oriented. This is truly an advantage because of the large effort made over the last few years to train programmers to think in terms of objects and designing systems this way. Object-oriented programming has been demonstrated repeatedly to improve productivity through a systematic approach to object design and analysis.
Java's object-oriented structure and platform independence are also enabling it to be quickly "retrofitted" to Component Object Request Brokers for use in building distributed applications. In fact, the Netscape Navigator 4.0 Web browser will include ORB client software by Visigenic for use in building distributed, object-based applications using the Netscape Open Network Environment (ONE) platform.
Even though Java was introduced by Sun Microsystems, it remains largely a vendor-neutral architecture. Sun Microsystems originally developed the JVM for Sun Solaris, Apple Macintosh, and Windows 95/NT, but JVMs have now been developed by many other corporations, including IBM, Microsoft, and Netscape. Developers deciding to develop applications using Java can choose from a broad range of tools from a variety of vendors and are not tied exclusively to Sun Microsystems' line of products.
Java also has the advantage of widespread acceptance and near-ubiquity. It is rapidly becoming the programming language of choice for Web solutions and is being used for actual product development now for things like Web server software, collaboration systems, and desktop applications. Business analysts often discuss the topics of market share and mind share. While market share is of course the universal indicator used to judge the success or failure of a product, mind share is a much more difficult and subjective indicator to measure. For developers trying to decide whether to implement a pure Java solution or an ActiveX solution, the decision becomes extremely difficult because of these two measuring sticks.
In terms of product support and existing lines of code, ActiveX is the market share leader because it effectively existed as OLE for several years already. However, developers who try to keep a finger on the pulse of the computing community realize that Java has captured an ever-increasing mind share of the programming audience. For Sun Microsystems, the maturation of Java and its role in it will determine if that mind share can be converted into market share at a future time for its software and hardware products.
A lack of existing code and experienced programmers in some ways are drawbacks to implementing standard Java applications. Although advanced class libraries, thousands of existing controls, and several excellent tools exist for the ActiveX developer, the Java programmer is often forced into the "roll-your-own" mode of development. Naturally, it is through this trial by fire that beginning Java developers turn into expert Java developers, but in some cases the business case for new Java development might be hard to sell when compared to existing partial solutions that already exist in the form of ActiveX.
For example, several ActiveX controls that enable developers to create impressive charts and graphs that appear to the user as full-featured mini-applications now exist. These controls are relatively inexpensive ($99-$299) and many employ internal object models for ease of development. To date, there is no Java applet available that approaches the sophistication of these controls, and because of Java applet's security restrictions, some features on these applets might never be implemented to compete directly with their ActiveX counterparts.
The huge interest in Java and its related technologies has also made it increasingly difficult for businesses to find truly qualified programmers. It is common to hear HTML designers who have included an applet within a Web page refer to themselves as Java programmers. The truly seasoned developer can use the Web to his or her advantage however, by publishing work samples on the Web for all to see. A well-placed URL on a resume can go a long way to quieting someone's anxiety when they examine your resume.
Perhaps Java's biggest drawbacks come in the area where it is the most visible: the Web browser client. Because rogue applets can damage a user's system, the designers of Java built it around a strict security model that treats applets extremely carefully within most Web browsers. This security model prevents applets from
Java applets also have no persistence. Because Java is object-oriented and each class can derive from another class and implement several interfaces, when an applet is uploaded to a Web browser, it can require the uploading of one, two, maybe twenty other class files with it. Because these applets are not persistent, the next time the user visits that Web site, this same group of applets will need to be reloaded all over again. In an intranet setting where users will continually upload the same Java applets over and over again, it is possible that the users could install local versions of these applets, but Java provides no "self-installation" capabilities.
One final weakness of Java that should be pointed out is that it is an interpreted language and suffers from poor performance without the existence of a Just-In-Time compiler. Just-In-Time (JIT) compilers actually compile Java code into native machine code on the fly after the applets have been downloaded so that the applets can have improved performance. This feature is included in the Netscape Navigator 3.0 browser and the Microsoft Internet Explorer 3.0 browser. Even with the existence of a JIT compiler, Java code still runs slower than comparable "C" code, and this point should be considered. A general rule of thumb is that whenever a task is I/O-bound (such as user interface operations), the slower language probably will not make a difference. However, in tasks that are CPU-bound (such as mathematical operations), the interpreted language will force your code to take a performance hit.
Native ActiveX controls are natively compiled, dynamically linked code modules that run without the aid of an interpreter. This enables them to boast a performance advantage over comparable Java applets. Although it is easy for developers to say that machines today are fast enough where performance differences probably will not matter, keep in mind that we are often writing for the lowest common denominator. I have been in many situations in which software ran just fine on my souped-up development machine only to see it suddenly crawl on a user's less-capable box.
ActiveX controls also are, for better or worse, persistent on a client's local systems after being downloaded the first time. At the present, Microsoft Internet Explorer does not automatically remove these controls when the browser exits. Instead, these controls reside indefinitely until the user deletes them. Microsoft has stated that control removal will be an option in later versions of Internet Explorer.
Some ActiveX technologies such as ActiveX controls also benefit from the large existing code base. Well over 1,000 ActiveX controls currently exist that will run within an Internet Explorer or Netscape Navigator page. This is a double-edged sword however, because the Windows platform is the only platform on which these controls can be used. Platform-dependence is without a doubt the primary drawback to implementing ActiveX Web sites. Until COM becomes available for other popular operating systems such as Macintosh and UNIX, ActiveX might remain primarily an intranet development technology. This is because within an intranet, Web designers usually are able to pinpoint exactly which machines will be using a Web-based application and can plan their design accordingly.
ActiveX controls have a truly distinct advantage: language independence. These controls can be built using a variety of popular products including Visual Basic 5.0, Visual C++, Delphi, and future versions of Visual J++. In addition, they are not simply a Web-only solution. As mentioned earlier, ActiveX controls currently are being used by Delphi, Visual Basic, C++, and even COBOL developers worldwide. This capability alone ensures that ActiveX will continue to grow in the future regardless of the success of Java and other technologies.
The lack of browser support could possibly slow the adoption of ActiveX for Web-based development. Because Netscape Navigator is the market leader (remember the discussion on market share earlier?) and because Netscape has chosen not to implement ActiveX support within its browser, users are being forced to decide between the two market leaders, Microsoft and Netscape. Although users can download an ActiveX Netscape plug-in from NCompass Labs that will enable Netscape to use ActiveX controls, very few users (relative to the total number of users) have chosen to do so. Once again, the topic of mind share versus market share is brought up. If Microsoft Internet Explorer suddenly experiences a dramatic increase in mind share among "power users," this could only help ActiveX and its related technologies. One can only hope that the end user will be the eventual winner of the browser "wars," and that the best technologies will survive in the long run.
Visual J++ is an extremely powerful development tool that can be used for a wide variety of undertakings. Java applets and applications can be created using this product making it a valuable resource for the World Wide Web programmer who decides to program using the Windows platform. In addition to these capabilities, Visual J++ is the first tool to enable Java and the Component Object Model (COM) to be combined in the application development process. The Windows Virtual Machine for Java enables Java classes to be treated as COM objects. Because of this, Java classes can be used both for interactive Web content as well as for building powerful Windows-based applications.
Visual J++ also will enable the reverse process to take place. In other words, COM objects can be used side by side with Java objects to produce the most powerful (and flexible) application possible. Capabilities within Microsoft's Internet Explorer browser enable this functionality to be carried over to the Web as well.
COM objects that act as plug-and-play programming tools are known as ActiveX controls. These controls are descendants of the popular VBX controls introduced in Visual Basic 3.0. ActiveX controls are programming objects that expose a set of properties, methods, and events that can be used by the programmer to construct applications from other's code. Because COM is a language-independent standard, ActiveX-enabled Java classes can now be used in common Windows programming environments such as Visual J++, Visual C++, Delphi, PowerBuilder, Visual Basic, Access, and many others. ActiveX-aware applications such as the Microsoft Office suite (Word, Access, Excel, and PowerPoint) can also use ActiveX controls to create powerful, custom-built applications.
In short, Visual J++ satisfies the needs of Web developers and also introduces Java to a much broader programming audience. Using this tool, Java might soon be the Windows programming language of choice as well as the unquestioned programming language of choice for the World Wide Web.
At the end of the chapter you learned the strengths and weaknesses of the Java and ActiveX technologies. Issues such as performance, platform-independence, and vendor support will apparently continue to be key factors in designers' decisions despite the early promise of the World Wide Web.