JavaBeans and ActiveX go head to head

Don't choose until you've considered these 5 issues crucial to developers

One area of intense software investment is in the creation of rapid-application-development (or RAD) packages. A RAD package consists of a programming language, a component model for connecting together interaction elements (called "controls"), and a customization environment (called "resource editors"). One of the most successful RADs on the PC has been Borland's Delphi; however, the first RAD to see widespread use was Microsoft's Visual Basic. Borland's product used a proprietary version of Pascal (Object Pascal) and Microsoft's product used a proprietary version of Basic. Because of Java's strengths as a robust, secure programming language, it seems a natural fit as the base language for a killer RAD environment; until now, however, Java has lacked a fundamental technology: components.

Software components are simply a convention for writing user-interface controls so that the application development tools and runtime environment can manipulate them. Visual Basic's component model, "VBX" (for Visual Basic eXtensions), is a variation of Microsoft's DLL (dynamic-link libraries) architecture. Delphi defined a component architecture around Borland's "OWL" (Object Window Library) architecture.

Not content to sit idly by and watch the action, JavaSoft has thrown its hat into the ring with a component architecture called JavaBeans.

You might think that this is simply the tale of three different RAD environments, each with their own language. You'd be right in one sense, but you know as well as I do that nothing is quite so simple. The Java language has injected a significant kink into the way programmers are taught to think. That kink was felt most strongly at Microsoft, which saw another competitor to its Visual Basic on the horizon. It was with this in mind that Microsoft took some existing work on generalizing VBXs for its other programming languages and created ActiveX -- a component architecture allegedly suitable for all languages. To reinforce this point, Microsoft has provided support in its newest development tools to invoke ActiveX controls from Java and to invoke Java from ActiveX controls.

Software component models

Let's begin with a simple definition: A software component model is a specification for how to develop reusable software components and how these component objects can communicate with each other.

With that said, we can now focus on how component models work in a general sense.

Developers of software components must deal with the low-level details of implementing a component and its associated classes. Users of software components (developers in their own right) can then simply hook together existing components in a visual development environment. This is what we call rapid application development -- existing codebase can be easily reused (or purchased from an independent vendor) and integrated in a third-party development environment. Component developers also benefit from this type of environment: They can reuse existing components, obtaining a consistent object-interface to many standard system facilities during the development of their own components.

In effect, software development with a component object model is like building with Legos building blocks. Instead of building an entire application from scratch, you build an application by hooking together your existing building blocks. This approach not only saves time, money, and effort, but it produces more consistent, reliable applications. And your mother told you playing with toys wouldn't get you anywhere!

In the context of GUI components, developing software with a component object model allows you to purchase or develop software components, such as font selectors and database viewers, and then put them together in a graphical development environment as easily as you would the native GUI components of your chosen environment. Configuring these components is then accomplished via graphical control panels that list the accessible properties of the components (color, font, etc.) and allow for easy modifications. I must stress, however, that components do not have to be solely graphical in nature. An alarm is an example of a typical non-graphical component: When you add it to an application you can graphically choose how frequently the alarm goes off and can easily edit the alarm code, but when your application is run the alarm component consists of a thread with no visual appearance.

Getting down to the nitty gritty:

Understanding the software components themselves

In order for a software component model to work, each software component must provide several features:

  • The component must be able to describe itself. This means that a component must be able to identify any properties that can be modified during its configuration and also the events that it generates. This information is used by the development environment to seamlessly integrate third-party components.

  • The component must allow graphical editing of its properties. A RAD environment is intensely graphical; the configuration of a software component is done almost exclusively through control panels that expose accessible properties.

  • The component must be directly customizable from a programming language. Because components also can be connected by scripting languages or other environments that can only access the components from a code level, this feature also allows software components to be manipulated in non-visual development projects.

  • The component must generate events or provide some other mechanism that lets programmers semantically link components. This means that the programmer can easily add the appropriate action code to buttons so that button clicks will properly affect other components.

In theory: scrutinizing the frameworks

Now that we understand the features a good software component should support, we can apply what we've learned to the JavaBeans and ActiveX frameworks specifically. We'll start with JavaBeans.

The JavaBeans way

JavaBeans supports autodescription through an introspection mechanism, graphical component editing through a customization mechanism, and linking through an event model. Let's look at how each of these features works.

JavaBeans supplies the Introspector class to perform introspection of a component (in this case, a "bean") automatically. A JavaBean can be studied to determine its properties and events in one of two ways: through the Reflection API or through the BeanInfo class. The Introspector class uses the BeanInfo class if it is supplied; otherwise, it uses the Reflection API.

With the Reflection API, one class can examine the methods provided by another class. If the bean author follows the JavaBeans design patterns specification, the behavior of the bean can be determined automatically from its method names. Alternatively, the bean author can provide a BeanInfo class that describes the bean. This class must implement the BeanInfo interface, and its name must be formed by adding "BeanInfo" to the end of the bean's class name. The various descriptor classes that are returned by this interface are then used to determine the bean's features.

When a bean is added to an application, the development environment will allow users to configure the bean through a property sheet. The bean's properties are determined through the introspection mechanism, and then presented in a graphical form as a property sheet. Changes that the user makes to the bean's properties will then be applied through the appropriate bean methods.

Alternatively, bean designers can include their own customization class, which can provide a configuration wizard to guide the user's initialization of the bean. Custom configuration classes are created by implementing a Customizer class and returning the appropriate information from the bean's BeanInfo class. This allows for a much greater level of sophisitication in the customization of a bean, which can be important for complex beans such as database accessors.


Different beans are linked together through events. Every bean declares the events that it can fire. When a bean's application is assembled, the programmer registers listeners for these events. When an event occurs, all of the registered listeners are notified.

For example, a button bean can generate Action events. A class that is interested in this event must implement the ActionListener interface and register with the button bean. When the event occurs, the button will notify all of its listeners through ActionListener interface, allowing the appropriate action(s) to occur.

The ActiveX way

ActiveX is Microsoft's retooling of its existing component object model for the Web environment. Essentially, ActiveX provides the glue for components to communicate with each other, regardless of their implementation language and platform. This is not to say that a given ActiveX control binary is portable; rather, it means that the specification allows for communication between controls on different platforms that support ActiveX. ActiveX is built from several core Microsoft technologies:

DCOM, Microsoft's distributed component object model, provides the low-level, object-binding mechanism that lets objects communicate with each other and remote objects. An extension of DCOM represents the ActiveX core technology. Like Java's remote method invocation (RMI), DCOM provides transparent message-passing between objects that may reside on different machines and different operating systems.

OLE (which Microsoft says "used to be" an acronym for object linking and embedding, but "has progressed far beyond compound documents") uses DCOM to provide high-level application services, such as linking and embedding, to let users create compound documents. Built on the foundation of Microsoft's component object model (COM, the predecessor to DCOM), OLE is optimized for end-user usability and integration of desktop applications.

ActiveX, as an improvement on OLE, provides a substantially "slimmed down" infrastructure that enables controls to be embedded in Web sites and respond interactively to events.

ActiveX controls describe themselves through a binary description file that lists the properties, methods, and events that should be exposed. Creating this interface from Visual Basic or Visual C++ is done through an ActiveX wizard that visually steps users through the process. Currently if an ActiveX control is developed in Java, then all of the public methods of the class are exposed by COM. It is likely, however, that Visual J++ 1.1 will introduce a wizard to refine this process.

Similarly, an ActiveX property page is visually created by a property page wizard that steps through the process of creating a graphical property editor. Currently, Java controls do not support a property page, but Visual J++ 1.1 should remedy this limitation.

As I mentioned earlier, ActiveX controls communicate through the low-level DCOM mechanism that allows controls to access each other's exposed methods, regardless of whether the controls reside in the same container, in the same machine, or on different machines. DCOM makes it possible for designers to develop applications that operate across heterogeneous networks, providing it has been ported to the respective platforms.Microsoft has released the DCOM technology to The Open Group, formed in early 1996 by the consolidation of two open-systems consortia: X/Open Company Ltd. (X/Open) and the Open Software Foundation (OSF). The Open Group (TOG) will oversee the DCOM standardization process.

ActiveX controls are linked through events; the development environment allows developers to create methods that are called when events are initiated by any components being used. If an event includes parameters (such as x and y coordinates) then these are included in the signature of the method that is called.

Blessing or curse?: Microsoft's automated approach

The maturity of Microsoft's development tools really shows in the context of ActiveX development. There is a vast amount of work that goes on behind the scenes when the wizards effortlessly guide you through developing and interoperating ActiveX controls; for example, the controls must be assigned unique identifiers, they need to be inserted in component registries, and so on.

If details in this section appear to be lacking, it is because they are hidden. Microsoft's development tools are intensely visual and intensely automated. So much work is done automatically that it is easy to develop with little knowledge of the internals of ActiveX, but it is a painstaking process to uncover the real details; even Microsoft's development documentation admits to this problem. Suffice it to say that without an advanced Windows IDE it would be practically impossible for a newcomer to develop an ActiveX control from scratch, but with such an IDE the tedium is automated away and a very powerful mechanism is exposed.

In practice: How the ActiveX and JavaBeans cope in the real world

JavaBeans and ActiveX are new technologies, and both are targeted at Web-based applications, which opens a huge can of worms when it comes to security -- developers must consider the treat of executing potentially dangerous code from arbitrary Web sites. These and other practical considerations between the two technologies are discussed in the following sections.


To be fully operational, JavaBeans requires the JDK 1.1, which is due any day now. However, the BDK (JavaSoft's Bean Development Kit) is available along with the JDK beta 1.1, and Symantec's Visual Cafe provides beans support under 1.0.2. These environments ship with a nominal introductory set of beans, and allow developers to begin creating JavaBeans apps. IBM's AppletAuthor also is avavailable now for JavaBeans development.

In terms of availability, ActiveX has taken the lead in the race at this point. ActiveX is currently supported by Microsoft's Visual Basic 5.0 (CCE), Visual C++ 4.2 (enterprise edition), and Visual J++ 1.1 (now in beta). For development, Macintosh SDK support is available now (in beta), and thousands of controls -- including RealAudio players, movie players, and graphical networked chat systems -- are currently available for purchase. And major Java tools vendors, incuding Borland and Metrowerks, have announced Java support for ActiveX.

In addition, an application can be put together in minutes from ActiveX components written in different languages, and the Microsoft Developer Studio will automatically switch debugging mode between the component languages as the application executes.

Grades for Availability:

  • JavaBeans: B (for beta)
  • ActiveX: A- (full Java support is still beta)


If you run a standalone JavaBeans application or a trusted applet, it will have all the power and capabilities of any Java aplication. However, if you run an untrusted JavaBeans applet (an applet not digitally signed by a trusted source), its capabilities are as restricted as any standard applet. (For details on trusted and untrusted applets, see the Security section below.) Note well the severe lack of multimedia capabilities and the current poor performance of Java. Future Java environments will offer a tiered range of security options for downloaded code, which will expand the capability of applets toward that of native applications. However, Java's limited API will remain a problem.

An ActiveX control, by contrast, has all the power of a native application, which allows it to take advantage of powerful native APIs, such as DirectX, OpenGL, and QuickDraw 3D. Java does not immediately offer this capability. Future APIs will improve this situation, but if you require access to a low-level system resource, only ActiveX provides the opportunity -- of course, at the cost of locking your application to a single platform.

Grades for Capability:

  • JavaBeans: B (limited API)
  • ActiveX: A- (capability is Windows-specific)


JavaBeans and ActiveX have radically different security models. As far as security is concerned, we must consider two aspects: For Web deployment, security must protect users against harmful code that is deployed with deliberate intent of doing harm. To date, such code is rare, but there are some significant demonstrations including the ActiveX Exploder and the exploits of Germany's Chaos Computer Club. (See the RESOURCES section below for more info.) Perhaps more importantly, however, a component model must provide safety that protects the user from accidental programmer errors that could cause damage.

JavaBeans relies on Java for its security. The Java security model includes intrinsic security that protects the user from errors that can result from incorrect type casting or illegal memory accesses. This provides both safety and security. In addition, a SecurityManager provides resource-level security that restricts a Java program's access to the disk, to the network, and so forth. This is important because the user is protected against both hostile and erroneous code. The Java runtime environment defines the level of resource access available to a Java program. Currently, Java applications have unlimited resource access and Java applets have extremely limited resource access. JDK 1.1 introduces digitally signed applets that allow the user to allow extended resource access to applets that come from a trusted source. The digital signature verifies that the applet comes unchanged from the source, so if you trust JavaSoft and an applet is signed by JavaSoft and you trust the authority that verifies the signature then you can give the applet extended resource access, safe in the knowledge that no one has tampered with the code. Remember that Java's intrinsic security is still there, providing protection against many programmer errors that could potentially lead to the applet causing damage. Furthermore, future browsers will allow certain extended resource access to untrusted applets (for example, write access to a certain directory). This security model means Java programs can be securely run, and safely granted resource access, depending on your trust in the origin.

ActiveX controls are not subject to any similar intrinsic security checks or resource access checks. Instead, controls run with full access to your machine and its resources. Digital signatures provide the only security mechanism: They allow you to verify that a control is unaltered from the source. To sign a control, you present it to a well-known certification authority (CA) such as Verisign, along with a description and your own name. The CA then uses encryption techniques to generate an unforgeable signature that verifies the control, your name, and its description. When a browser encounters a signed control, it uses its own copy of the CA's public key to verify that the control matches the signature; if it does, then you can be sure that it is unaltered since it was submitted to the CA. Look in your browser's security options to see the public keys to which you have access.

The lack of resource control makes ActiveX an extremely powerful technology: Witness the controls that power-down your machine, that automatically upload all of your Word documents and publish them in HTML, and that instruct Quicken to perform a funds transfer from your bank to another bank without ever asking your permission. These may seem like nightmarish applications, but they also demonstrate the great potential that ActiveX has for significant (Windows-based) intranet applications.

On the other hand, the lack of intrinsic security unfortunately leaves a huge hole in the ActiveX security model, at least for using non-Java ActiveX controls on the Internet. If a control does not perform complete parameter-checking, a digitally signed control could be coerced into performing arbitrary operations on the user's machine. The typical scenario is for a parameter to overflow a buffer, overwrite a return address on the stack, and cause execution to jump to an arbitrary location. Should such a programming error be discovered in an ActiveX control, an unscrupulous developer could then alter (possibly for fraudulent means) the control's behavior under the guise of the author. To do the same with a signed Java applet, you must discover a bug in the Java virtual machine (JVM) because Java's intrinsic security (safety) normally prevents this problem. There are only a few JVMs out there and they are all undergoing intense scrutiny for such errors. Can the same be said for the thousands of signed controls currently available?

Digital signatures are a valuable technology if they are used to support a secure environment such as Java, because they allow significant applications to be securely deployed on the Internet, with appropriate resource access to client machines. If you agree to execute a control signed by Germany's Chaos Club, though, you are inviting trouble. What's frightening is the possibility of a legitimate ActiveX control, signed by a firm such as Microsoft, being coerced into subversion. Such a problem has not yet occurred, but with the number of bugs that have been found in JVMs to date, it is not such a far-fetched idea.

Grades for Security:

  • JavaBeans: A (wide range of security options)
  • ActiveX: D (provides no safety and no Internet security)


Top among the design goals of the JavaBeans specification was interoperability with other component environments. Bridges are planned that will link to such environments as COM, OpenDoc, and Netscape ONE. Through these bridges, objects from different models will be accessible through the JavaBeans interface. Unfortunately, details are scant at this time.

ActiveX is supported by at least three full languages and can be scripted with several languages, including VBScript and JScript. Because ActiveX has full system access, interoperability with almost any system available on the target platform is possible. For example, you can develop an ActiveX control in Visual Basic that opens a window and adds a C++ AVI player (an ActiveX control), and then operate the player from a Java applet. Currently some limitations exist with regard to a Java container holding a non-Java component, or a non-Java container holding a Java component. However, Microsoft most likely will address these limitations in the future.

Grades for Interoperability:

  • JavaBeans: B- (an ActiveX bridge has been demonstrated, but it's not all available)
  • ActiveX: B+ (it's not perfect)


JavaBeans obviously wins the cross-platform game. The Java VM is already available across most popular operating systems; it's even available for a variety of unpopular operating systems. And the early teething problems of cross-platform GUIs are finally settling down.

Despite some marketing hype (releasing DCOM to The Open Group), ActiveX is not a cross-platform solution. If you write an ActiveX-based application, it will only run on its target machine and operating system. It is possible to package up multiple versions of a control for different platforms so that the correct version will be correctly executed, but if you take advantage of any Windows API, then your application will require significant porting to execute under any other platform -- even if that platform supports ActiveX.

Grades for Cross-platform prowess:

  • JavaBeans: A- (Java's cross-platformability loses too many platform-specific features)
  • ActiveX: D+ (in theory you could write to ActiveX on multiple platforms, but any given control is not portable)

So what does it all add up to?

With this article I've strived to give you the information you need to effectively determine which component model you should adopt. If, however, after reading this article and noting how well JavaBeans and ActiveX each scored on the five crucial areas covered in the In practice section above, you still need some guidance, keep reading.

If your application fits cleanly within the 100% Java world, then develop with Java, and develop to JavaBeans specs. If your application fits within the Windows world, then develop with ActiveX. Use Java, C++, Visual Basic, or combinations as appropriate. ActiveX represents a great solution for the rapid introduction of existing code to the intranet. That much is obvious.

If your application must be deployed across the Internet, then given the security considerations, Java/JavaBeans is the only option. Our corporate security policy for ActiveX is as follows: If we wrote it and it came from within firewall1, it's okay; otherwise, it will not execute on our machines. In general, significant user education is required about when and where not to execute untrusted code; in my opinion, a user should not be able to automatically execute a control without first being warned of the dangers.

On the other hand, if you are looking at intranet deployment, then you must weigh the pros and cons of cross-platform (JavaBeans) versus Windows integration (ActiveX); the security considerations of ActiveX are not relevant. For many applications, ActiveX will win simply because it is ready, it is working, and if you wish to develop Java ActiveX applications that take advantage of your existing Windows code, you can. On ther other hand, ActiveX becomes very complex if you dig beneath the surface and, despite certain marketing efforts, completely lacking in cross-platformability. If you can live with 100% pure Java and the immaturity of full IDEs, JavaBeans offers a very attractive cross-platform opportunity for long-term development efforts.

For all involved, however, I would recommend that a more-than-casual glance be given to the opposite end of the field. It is very easy to dismiss one or another technology out of hand; however, any serious developer should be aware of the real technical capabilities and limitations of the available options.

Keeping your eyes on the future

The future is hard to judge given the ever-changing nature of the present, but the following assessments are fairly obvious: Microsoft will embrace JavaBeans by exposing all JavaBeans as ActiveX controls. Whether it adopts JavaBeans as the framework for developing full-fledged ActiveX controls in Java is less clear. JavaSoft and third parties will release full-fledged JavaBeans-enabled development environments that will, for the first time, open up Java to VB-style rapid application development. One thing is for sure: The battle will continue to rage.

Merlin Hughes is VP of Technology at Prominence Dot Com, lead author of Java Network Programming by Manning Publications Company, and co-author of JavaWorld's monthly Java Step By Step column. Merlin has no free time, but he enjoys Coca-Cola and eats at Pizza Hut. His motto: Guinness for strength; Jack Daniel's for the day after.

Learn more about this topic

  • Microsoft resources
  • JavaSoft resources

Join the discussion
Be the first to comment on this article. Our Commenting Policies