Article ID: 243771 - View products that this article applies to.
This article was previously published under Q243771
This article has been archived. It is offered "as is" and will no longer be updated.
This article describes why Internet Explorer looks for a BeanInfo class even when your development project does not target the Java Beans specification.
The Microsoft virtual machine (Microsoft VM) uses a feature called Auto-IDispatch to expose all Java objects as Component Object Model (COM) objects. This COM integration feature is a dynamic construction of a default IDispatch interface for Java objects, which exposes public methods and fields to other objects that support COM. When a Java object is non-visual, the reflection application programming interface (API) is suitable for this task. However, when a Java object is a visible component, such as an applet, the Microsoft VM goes one step further and exposes these beans as ActiveX controls.
The BeanInfo class is part of the Java Bean API that component design and rapid application development (RAD) tools use to persist bean state. Because ActiveX controls are similar to Java beans in purpose and design, the Introspection API for beans is suitable for the Auto-IDispatch feature for visual Java objects. Therefore, when the Microsoft VM throws a ClassNotFound exception for the BeanInfo class, the Microsoft VM could not find a custom BeanInfo class and generated a default (empty) BeanInfo class instead.
NOTE: When an applet is located on a Web server, the Microsoft VM goes back to the Web server and searches the applet directory before it creates the default empty class. To prevent this additional "hit" on the Web server, you must include a BeanInfo class with the applet code.
For more information on how ActiveX and Java Beans work together, please refer to the following Web site:
For support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site:
Article ID: 243771 - Last Review: January 6, 2015 - Revision: 3.0