Java's promise to provide a platform-independent programming language has resulted in its rapid growth in popularity. This popularity has led to some opposition, principally by industry-giant Microsoft. Although Microsoft was one of Java's original licensees, it has done little to advance Java's platform-independent appeal, instead opting to tie Java to its Windows platform. This has resulted in a significant impact on the Java programmer.
In this chapter, you'll learn about Microsoft's impact on Java and about the capabilities of the Visual J++ development environment. You'll also learn how Java can be integrated with legacy Component Object Model (COM) technology and how the Java plug-in can be used to provide full JDK support across browser platforms. When you finish this chapter, you'll have a thorough introduction to the pitfalls and advantages of Microsoft-style Java.
One of the biggest controversies in the Java world in the last year has been Microsoft's subversion of the Java API. Microsoft's failure to implement the full JDK 1.1 with their Internet Explorer 4.0 browser has landed them a lawsuit from Sun Microsystems. From its initial release in 1995, Java has been perceived as a threat to Microsoft's hegemony in the PC operating system world. An omnipresent, platform-independent Java could result in the Windows platform being relegated to a one-among-many carrier of the Java runtime system, and Microsoft's leverage in the PC operating system and application software market could be significantly eroded. Microsoft fought back against Java with their typical tactics--using their dominance in the PC operating system world to build a better but non-standard product. Their Visual J++ 1.0 and 1.1 development tools provide excellent access to Windows-specific resources. However, using these capabilities eliminates Java's "Write Once, Run Anywhere" features.
Sun fought back with its 100% pure Java campaign. Visual J++ amassed a large market share among Java development tools nevertheless, but its popularity among serious Java developers was eclipsed by pure Java tools, such as Symantec's Visual Café and Sun's Java Studio. In addition, many hardcore Java programmers have forsaken the niceties of these visual programming tools and still use the JDK tool set.
On another front, Microsoft's battle with Netscape in the browser wars had a significant impact of JDK 1.1 software development. Both Netscape and Microsoft were significantly behind schedule in implementing JDK 1.1 support in their version 4.0 browsers. Netscape provided incremental JDK 1.1 support that eventually encompassed the entire JDK 1.1 API. Microsoft provided support for a majority of the JDK 1.1 API. However, having wrested browser dominance away from Netscape, Microsoft simply declared their browser to be JDK 1.1-compliant without providing full JDK 1.1 support. This eventually led to Sun filing a lawsuit over Microsoft's failure to live up to the terms of using the Java-compatible logo. At the time of this writing, the court had ruled that Microsoft could not use the Java-compatible logo with Internet Explorer 4.0.
The impact of Microsoft's actions on Java applet developers was that they could not use all of the JDK 1.1 features in their applets and still be compatible with Navigator, HotJava, and Internet Explorer. This stifled JDK 1.1 applet development.
One of the JDK 1.1 APIs conspicuously left out of Internet Explorer 4.0 is the Remote Method Invocation (RMI) API. RMI's popularity has eclipsed industry interest in Microsoft's solution to distributed object programming--the Distributed Component Object Model (DCOM). DCOM is the combination of two legacy technologies--the Component Object Model (COM) and the Distributed Computing Environment (DCE). An RMI-capable Internet Explorer could obviate the need for a flailing ActiveX (COM spinoff) and DCOM. Microsoft's tradeoff between providing complete JDK 1.1 support and eliminating ActiveX/DCOM competition has resulted in a significant inconvenience to the Java programmer.
NOTE: Chapter 37, "Distributed Application Architecture," provides an introduction to COM and DCOM.
The Microsoft JVM is a reimplementation of the JavaSoft JVM that provides additional Windows-specific features. These features allow Java code to access native Win32 code, such as ActiveX components, dynamic-link libraries (DLLs), and COM interfaces. The J/Direct feature allows Java code to access DLLs without going through the Java Native Interface (JNI). The advantage of J/Direct is that it is more efficient and easier to use. Its disadvantage is that it reduces the portability of Java code between operating system platforms.
The Microsoft JVM also supports ActiveX/JavaBeans integration. This support allows ActiveX components to be accessed as JavaBeans and vice versa. This interoperability between JavaBeans and ActiveX makes a large number of ActiveX components available to Java programmers. It also allows beans to be used within the COM environment. These advantages are offset by the fact that using ActiveX confines applications to Microsoft Windows platforms, a high price to pay for a Java programmer. The capability to access JavaBeans from a COM environment is certainly a boon for Windows programmers.
The Microsoft JVM also supports the Raw Native Interface (RNI), which provides highly efficient access to native code from Java. The RNI is not compatible with JavaSoft's JNI. The RNI requires native code to conform to Java constraints, such as naming conventions, data representation, and garbage collection. Use of RNI requires the native code programmer to be familiar with low-level Java programming details. RNI can provide very high code performance at the expense of complexity and lack of portability.
COM is Microsoft's legacy to object-oriented programming. Although COM lacks some object-oriented programming features, such as true inheritance, it is widely used throughout the Windows world. Support for COM is one of the primary features of the Microsoft JVM. This support allows Java code to access COM objects as Java classes.
Visual J++ is Microsoft's development environment for Java. Visual J++ 1.0 corresponds to the JDK 1.02 and quickly became popular for its low cost, full development environment, and fast compiler. Microsoft also included the Microsoft JVM with Visual J++, providing support for ActiveX and COM. Of course, the objective for this support was to skew Java's use toward the Microsoft Windows family of operating systems and the Internet Explorer browser. Visual J++ 1.0 provides a number of features that makes it more attractive than the tools of JDK 1.02.
In addition, Microsoft priced Visual J++ very low. This made it very competitive with high-end visual Java programming tools, such as Symantec's Visual Café and JavaSoft's Java Studio.
Visual J++ 1.1 was released in the same timeframe as the JDK 1.1. However, Visual J++ 1.1 provided little support for the JDK 1.1 API. Instead, it introduced the Application Foundation Classes (AFC), a Microsoft API that supports GUI development and graphics effects.
Visual J++ 1.1 also includes the following features:
Visual J++ 6.0 is Microsoft's latest version, released at the same time as the JDK 1.2. (Microsoft must have been so impressed with the new version that it skipped versions 2 through 5!) Visual J++ 6.0 adds a number of features that lock it tighter with Windows programming and ignore Java's platform-independent programming capabilities. These features include the Windows Foundation Classes (WFC), which is another attempt to substitute a Microsoft API for a JavaSoft API. The WFC promotes even greater dependence on Win32, Microsoft's version of Dynamic HTML (DHTML), and Internet Explorer. WFC takes advantage of J/Direct technology in providing Win32 integration. This support includes access to the Windows clipboard, Windows threads, Windows registry, Windows messaging, OLE, ActiveX, DHTML, and other Windows-specific capabilities.
Other features included with Visual J++ 6.0 include the following:
For more information on Visual J++, check out the Microsoft Visual J++ Web site at http://www.microsoft.com/visualj/prodinfo/.
Microsoft's Java APIs include the AFC and the new WFC. In this section, we'll take a look at the packages comprising these APIs.
The AFC consists of five packages that provide support for graphics, GUI components, event handling, Win32 access, and .CAB files. These packages consist of the following:
The WFC consists of 10 packages that provide support for native Windows capabilities. These packages consist of the following:
At the time of this writing, the WFC were only in preview release 1. Additional capabilities may be present in the final WFC release.
The unifying principle behind Microsoft's JVM, Visual J++, and class libraries is the capability to integrate Java with COM objects. COM has been the hub of Microsoft's object-oriented software development strategy since Windows 3.1. It has undergone a few marketing name changes (OLE, OLE2, COM, and the recent ActiveX), but the technology centers around Microsoft's Component Object Model. As such, COM is very important to Microsoft's product strategy: operating systems, application software, and enterprise server software.
The existence of Java objects, separate from COM, poses a direct threat to COM's future. That's why it is so important for Microsoft to bring Java into its COM strategy. By integrating Java with COM, Microsoft can keep Java from becoming a wholly separate and competing object technology.
This strategy is flawed because COM is a legacy object technology and Java represents the future of object and component development. Rolling Java into COM is a step backwards in the evolution of object-oriented programming. However, the capability to integrate Java objects with COM objects is important to support Java migration while leveraging prior investments in COM technology.
Visual J++ 6.0 provides the jactivex command line tool, which enables COM objects to be accessed by Java objects. The jactivex tool generates Java source files that correspond to a COM object's type library. A type library provides a standardized description of a COM object's interfaces. The Java source files generated by jactivex provide the required Java-to-COM connectivity by wrapping the interface methods of COM objects. Java applications can then invoke the methods of the Java classes generated by jactivex, and these methods in turn provide a pass-through to the interface methods of COM objects.
NOTE: COM objects must be registered with the Windows Registry before they can be accessed.
The capability to access Java objects from COM is also important to any COM-to-Java migration strategy. The migration of legacy COM-based applications to Java can be initiated by selectively reimplementing and replacing COM objects with Java objects. To accomplish this, newly developed Java objects must present an identical interface to existing COM objects.
COM programming, like Windows programming in general, is full of arcane terminology and programming requirements. Fortunately, the Microsoft JVM and Visual J++ tools shield the Java programmer from the complexities of the COM world. For example, Java programmers don't have to worry about implementing the COM IUnknown interface, initializing COM objects, or retrieving interface pointers. Writing COM objects in Java is actually easier than writing them in C++.
COM interfaces are described using the COM Interface Definition Language (IDL). The IDL description of a COM interface is compiled into a COM type library using the Microsoft IDL (MIDL) compiler or the jactivex tool. The type library is then imported into your Java code. The jactivex tool generates an appropriate Java interface for the type library description. You then implement your COM object by implementing each of its interfaces (imported from the object's type library). To make the COM object available for use, you must register it with the Windows registry by using the javareg command line tool. The javareg tool is included with all versions of Visual J++.
Distributed COM, or DCOM, was introduced with Windows NT 4.0 and Windows 95. DCOM allows COM objects to be accessed remotely over a network. It's the integration of COM with the DCE remote procedure call (RPC) protocols and can be thought of as COM objects connected via Microsoft's implementation of DCE. Version 2.0 of the javareg tool (included with Visual J++ 6.0) allows Java classes to be registered as remote objects that can be accessed via DCOM.
In order to promote the widespread use of JavaBeans, JavaSoft developed the JavaBeans Bridge for ActiveX. This bridge allows Windows users to use beans in legacy Windows applications, such as Microsoft Office or Visual Basic. The bridge wraps beans in an ActiveX container that makes the beans appear as native COM objects to Windows programs. The purpose of the bridge is to give bean developers backward-compatibility with Windows. This means that you can write beans that take advantage of the latest Java advances and be sure that they will interoperate with legacy software. As such, the bridge allows a smooth transition path from Windows, COM, and ActiveX to Web-enabled, platform-independent Java applications.
The bridge consists of a utility that creates OLE type library information and Win32 registry information for a bean. This information is needed so that COM objects can correctly access and use beans. The bridge also allows bean events to be used by COM objects, thus allowing full interaction between the bean and its COM container.
The bridge also allows beans to function as COM servers. This allows other COM objects to invoke bean methods and use beans as building blocks in larger COM applications.
The JavaBeans Bridge for ActiveX is available from the JavaSoft Web site at http://java.sun.com:80/beans/software/bridge/.
While COM and ActiveX have played an important role in the development of components for Windows platforms, many software development organizations want to develop future components for the platform-independent Java runtime environment. In order to support this migration from ActiveX to Java, IBM, Taligent, and JavaSoft developed the JavaBeans Migration Assistant for ActiveX. This tool simplifies the process of porting ActiveX components to JavaBeans by using available ActiveX information to create equivalent JavaBeans interfaces. The tool identifies interface methods and their parameters and maps Windows types to their equivalent Java types. It also generates Java stubs for ActiveX components that are being migrated. Migration from ActiveX to JavaBeans is accomplished by implementing these interfaces in Java.
The JavaBeans Migration Assistant for ActiveX is available from IBM's Web site at http://www3.software.ibm.com/segdown?segment=AD&family=JV.
The failure of Microsoft and Netscape to provide complete JDK 1.1 support with their version 4.0 browsers put a dent in the development and deployment of JDK 1.1 applets. In order to prevent future versions of the JDK from being undermined, JavaSoft developed the Java Plug-In, formally named Activator. The Java Plug-In lets Web publishers specify the use of JavaSoft's Java Runtime Environment (JRE) in Internet Explorer (version 3.02 or later) and Netscape Navigator (version 3.0 or later). The JavaSoft JVM is used instead of the browser's default JVM. This assures applet developers that the applets they develop can use the latest version of the JDK and that they will be supported on the two most popular browsers. The JDK 1.2 Java Plug-In support is included with Win 32 JDK. An installation option allows the Plug-In to be used with Navigator and Internet Explorer. Java Plug-In is also available from JavaSoft's Web site at http://www.java.sun.com/products/plugin/index.html.
Web publishers are required to make changes to their HTML pages to specify the use of the Java Plug-In. When Internet Explorer or Navigator browsers process the modified HTML, they load the plug-in, which loads and uses the JavaSoft JVM with any applets contained in the HTML pages. JavaSoft provides an HTML converter that simplifies the integration of Java Plug-In with existing HTML pages.
When an Internet Explorer browser initially loads a Web page that specifies the use of the plug-in, it automatically downloads and installs the plug-in. This causes the latest JRE to be installed also. The initial installation can be time-consuming, depending on the user's computing power and network bandwidth. However, after the initial installation, the plug-in does not pose any additional performance impact. Navigator supports the same type of installation, although it is somewhat less automated.
In this chapter, you learned about Microsoft's impact on Java and about the capabilities of the Visual J++ development environment. You also learned how Java can be integrated with COM technology, and how the Java plug-in can be used to provide full JDK support across browser platforms. In the next chapter, you'll learn how the Java Command Language (Jacl) adds a scripting capability to Java.
© Copyright, Macmillan Computer Publishing. All rights reserved.