by Bryan Morgan
Visual J++ is Microsoft's first Java development tool. It was originally internally dubbed Jakarta after the largest city on the island of Java, but Microsoft decided to refrain 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, an 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++ toolset 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 the tool with just these capabilities, Visual J++ would be highly regarded for its excellent development environment and extremely fast compiler. It uses the Developer Studio environment, which is also 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 book 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 an extremely
nice development environment. 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 other objects running on machines elsewhere across the network. This allows applications to be partitioned across multiple machines in order to improve performance and improves maintenance time because only one machine needs be updated in the case of software updates. The term cross-platform is used throughout this book 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 an implementation of this standard can be found 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: Microsoft Visual C++/Visual FoxPro/Visual Basic/Access, Borland C++/Delphi, Powersoft PowerBuilder, and Oracle PowerObjects.
Why is ActiveX being discussed in a book about a Java compiler? This is what separates Visual J++ from every other Java tool on the market. The Visual J++ toolset, in combination with the Microsoft Windows Virtual Machine for Java, allows 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 allows Windows developers to utilize the full power and elegance of the Java language along with the huge existing base of COM objects that many developers have already invested in.
ActiveX is the name of a group of related technologies from Microsoft that is designed to allow developers to provide active Web content. Although ActiveX is currently 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 allow 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 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 allows users to concentrate more on an application's content than on the application itself.
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 allows ActiveX controls to be much smaller than their OLE counterparts. However, in many situations the control is required to implement the same interfaces.
ActiveX scripting extends the concept formerly known as OLE automation by adding scripting capabilities to Web pages, programs, and even server applications. ActiveX scripting allows 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. Here are a few examples of scripting hosts:
Scripting engines are currently available for Visual Basic for Applications (VBA); Visual Basic, Scripting Edition (VBScript); and JavaScript.
Common Internet protocols such as FTP and HTTP can make use of ActiveX technologies such as monikers (which are equivalent to OLE monikers). These monikers can server as pointers to applications and can be interpreted by ActiveX server products in order to link applications to the Internet.
An entire suite of ActiveX APIs is available through the ActiveX Software Development Kit (SDK). These APIs allow software developers to extend traditional Windows-based programs with Internet capabilities such as file transfer and Web server access.
The ActiveX server framework is actually an entire class of ActiveX technologies that can be used to provide server-side functions. Some examples of components within the ActiveX server framework are the Internet security framework (which includes items like the CryptoAPI, code signing, and Microsoft Wallet), database access using dbWeb, and the Normandy commercial service provider platform.
The final component of ActiveX to be discussed here is the Microsoft Windows Virtual Machine for Java. This Java Virtual Machine is designed both to run standard Java applets and to expose Java applets as COM objects for their use in ActiveX applications. The Windows Virtual Machine for Java also allows Java applets to coexist with ActiveX controls because, to the programmer, both are just objects composed of properties, methods, and events. The Microsoft WindowsVirtual Machine for Java is discussed in greater detail in Chapter 18, "The Microsoft Java Virtual Machine."
What does this mean for Windows and Java programmers? First, it means that these two groups can now be one and the same. Just as there are Windows VB developers and Windows C++ developers, soon developers will be able to select Java as the development language for new projects. 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 may become inaccurate to refer to Visual J++ as simply a "Windows tool" because COM is gradually becoming a cross-platform object model.
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:
As you probably know, these capabilities are included with virtually every Java tool on the market today. With the extra features that Microsoft has added to Visual J++, the Visual J++ programmer can take advantage of the previously listed features as well as the following four:
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 that will be reinforced throughout this book is that Visual J++ is a great tool to use for both 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.
As mentioned earlier, the Visual J++ programmer can take advantage of both Java and ActiveX when building applications in the Java language. This is what separates Visual J++ from other Java compilers currently on the market. The remainder of this chapter provides an overview of both the Java and ActiveX technologies and prepares the reader for more detailed topics covered throughout the remainder of the book. The goal of this book is to leave the reader with two primary skills:
Many developers may 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 or another. Before diving into ActiveX, however, you need to take a look at the history of the component object model (COM) and object linking and embedding (OLE).
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 is programmed to implement. (For instance, if an object wanted to be able to be saved to disk, it could implement what is known as a structured storage interface. This interface is defined by Microsoft to give objects the capability of saving their contents off to a file using a structured file format.)
Note that I used the words in theory in the first 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 only available for the Windows family of operating systems. Microsoft has recently announced plans to assist Metrowerks in porting COM to the Apple Macintosh, and the company is currently 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 the application will run. This possible drawback is discussed later in this chapter in the section "Advantages and Disadvantages: A Close Look at Java and ActiveX."
COM is both a specification and an actual implementation. The COM specification specifies a language-independent binary standard for implementing objects. 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 allow the programmer to instantiate a component object using a unique class identifier known as a class ID. These topics are discussed in greater detail in Chapter 16, "Java and the Component Object Model," in the section titled "Identifying COM Objects"; what is important to realize now is that COM, by itself, simply provides the "rules" by which objects can be instantiated and communicate among themselves. A group of COM objects can be combined to make an application. With the advent of distributed COM (DCOM), these objects can be located anywhere on a network. This functionality is currently provided as a core part of Windows NT 4.0.
Although COM is destined to be an integral part of future Microsoft operating systems, it 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 any number of 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 COM objects from scratch that are fully compliant with the binary specification, most Windows developers have never done this. Instead, programmers wanting the functionality provided by the COM object model have historically relied on OLE, a framework that lies on top of COM. OLE stands for object linking and embedding and is the parent of what is now known as ActiveX.
The wary reader may by this point be wondering where this discussion
is headed. After all, on one hand I have discussed the Web and
Java's use in building networked, platform-
independent applications. On the other hand, I have discussed
OLE and its capabilities for building object-based applications
on the Windows platform. Now you'll learn how the two technologies
can be brought together through the magic of COM and the 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 now 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, the previous section discussed 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; the resulting set of transformed technologies has been named ActiveX. Many pieces of this technology are portions of OLE2 that have been completely reworked for maximum performance benefits for Web usage, while others are OLE2 pieces that have basically been renamed and remarketed as ActiveX technologies.
Like its parent, OLE2, ActiveX cannot be summed up as one simple technology. Instead, it must be broken into several parts, all of which can be thought of collectively as Microsoft's ActiveX architecture. The following discussion highlights the key ActiveX technologies and attempts to draw a parallel between them and their parent OLE2 technologies.
Visual J++ is the first product to combine two extremely popular technologies: Java and COM. This can be done because, in fact, the two are extremely similar on many levels. This section summarizes the capabilities of Java and COM and discusses why they fit together so 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, whereas 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.
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. DCOM objects, meanwhile, can be stored on a remote machine and then be called from that remote machine using a remote procedure call (RPC).
Java applets are designed with specific security restrictions, including the inability to call code on any server other than the originating server and the inability to make local operating-system calls. COM objects, on the other hand, 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 is then 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 from memory. Memory management with COM also uses runtime tracking of objects to free them from memory when they are no longer used. Instead of garbage collection, however, COM tracks the reference count, or the number of instances that are using an object. When the reference count drops to zero, that object is freed from 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
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, while COM requires an implementation of the component object model for each specific platform. Once 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 may have noticed by now, both rely heavily on the use of interfaces. Interfaces allow objects to implement a related set of functions for an object. The intent of these interfaces is generally documented; thus 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, which allows 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. These strengths and weaknesses are discussed here so that you, the reader, 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 may be that it is the most powerful,
ubiquitous programming language that allows developers to create
platform-independent code. Unlike most other cross-platform
tools, the Java developer actually has to make an effort to add
platform-dependent code to the application at hand. Java programmers
can thank the availability of the Java Virtual Machine for this
feature. This is because all the platform-specific code is contained
in the Java Virtual Machine distribution for a particular platform.
This means that all the platform-specific work has already been
done for you by the creator of the virtual machine. The Java programmer
can simply concentrate on programming in Java.
| 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 design systems. Object-oriented programming has repeatedly been demonstrated 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 common object request brokers (ORBs) for use in building distributed applications. In fact, the Netscape Navigator 4.0 Web browser will include ORB client software by Visigenix for use in building distributed, object-based applications using the Netscape Open Network Environment (ONE) platform.
Although 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's 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. 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 the company's role in it will determine whether that mind share can be converted into market share at a future time for Sun's software and hardware products.
A lack of existing code and experienced programmers are drawbacks in some ways 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 situations the business case (or return on investment) for new Java development may be hard to sell when compared to existing partial solutions that already exist in the form of ActiveX. For instance, several ActiveX controls currently exist that allow developers to create impressive charts and graphs that appear to the user as full-featured mini-applications. 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 applets' security restrictions, some features of these applets may 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 haven't done more than include an applet within a Web page refer to themselves as Java programmers. The truly seasoned Java developer, however, can use the Web to his or her advantage by publishing work samples on the Web for all to see. A well-placed URL on a résumé can go a long way toward quieting a potential employer's anxiety when he examines your résumé.
Perhaps Java's biggest drawbacks come in the area where it is the most visible: the Web browser client. Due to the possibility of rogue applets damaging a user's system, Java's designers 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 (more on this in Chapter 3 "Object-Oriented Programming with Java"), when an applet is uploaded to a Web browser, it may require the uploading of 1, 2, or maybe 20 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, 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 and Microsoft Internet Explorer 3.0 browsers. Even with the existence of a JIT compiler, Java code still runs slower than comparable C code, and this is an important point to 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 allows them to boast a performance advantage over comparable Java applets. Although it is easy for us as developers to say that machines today are fast enough so that performance differences don't matter much, we should keep in mind that we are often writing for the lowest common denominator. I have been in many situations when software ran just fine on my souped-up development machine only to suddenly crawl on a user's less-capable box.
ActiveX controls also are, for better or worse, persistent on clients' local systems after being downloaded the first time. At the current time, 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 may remain primarily an intranet development technology. This is because within an intranet, Web designers are usually 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++. Another benefit is that they are not simply a Web-only solution. As mentioned earlier, ActiveX controls are currently being used by Delphi, Visual Basic, C++, and even COBOL developers worldwide. The capability to build controls in any language 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 allow Netscape to use ActiveX controls, very few users (relative to the total number) have chosen to do so. Once again, the topic of mind share versus market share is brought up! If the Microsoft Internet Explorer suddenly experienced a dramatic increase in mind share among power users, it 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 allow Java and the component object model (COM) to be combined in the application-development process. The Windows Virtual Machine for Java allows Java classes to be treated as COM objects. Because of this, Java classes can be used for interactive Web content as well as for building powerful Windows-based applications.
Visual J++ will also allow 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 allow 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 distant descendants of the popular VBX controls introduced in Visual Basic 3.0 and direct descendants of OLE controls. 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 others' 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 make use of ActiveX controls for the creation of 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 may soon be the Windows programming language of choice as well as the unquestioned programming language of choice for the World Wide Web.
This chapter included a discussion of 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. The purpose of the remainder of this book will be to educate you, the reader, on the capabilities of the Visual J++ tool in hopes that you can then use this newfound knowledge to make good decisions.
The following chapter introduces the Java runtime environment. This environment is comprised of several interrelated parts, including a Web server, a Web client, the Java Virtual Machine, and additional components. The chapter is a must-read for any programmer new to the World Wide Web and Java in particular.