| Yes, JavaBeans are another grating coffee pun. They're
also prewritten software components that make it easier to
build Java programs. Beans are to Java what OCX/ActiveX objects are to OLE and Live Objects are to OpenDoc. Some Beans are visual components that you add to forms in visual-development tools; other Beans are faceless objects that do something in the background. A Bean could be a cartoon or a piece of business logic. You could build a simple Java applet by assembling a bunch of Beans without doing any programming, or you could wrap some Beans in thousands of lines of proprietary code to build a sophisticated enterprise application. Because Beans are written in Java, they have two big advantages: They're cross-platform, and they're relatively easy to write. ActiveX objects and Live Objects are platform-specific binary files that are more difficult to write. (Beans are just specialized Java class files. In fact, all Abstract Windowing Toolkit [AWT] components are automatically Beans, because AWT in JDK 1.1 adopts the new JavaBeans event model. Anybody who has written a visual component that subclasses an AWT object has already written a Bean. Few have accidentally written an ActiveX control or a Live Object.) ActiveX and OpenDoc supporters often refer to their objects as "cross-platform," but they're really multiplatform: Someone has to port every object to every platform. Some platforms get more attention when it comes time to allocate precious development resources. Beans are based on existing Java objects, with four new features. JavaSoft defines a Bean as any Java object that implements at least one of these features. Introspection/reflection lets a Bean expose its data structures to other programs and to programmers. For example, a development tool could have an object inspector that lets a programmer examine a Bean's methods, instance variables, properties, and interfaces. A new event mechanism streamlines event handling and works with AWT components. (Java still supports the existing handleEvents() method for backward compatibility.) Because the new model uses less indirection and is more strongly typed, it's much more efficient, especially for high-frequency events like mouse movements. Serialization/persistence lets Beans permanently remember changes to their properties. Currently, objects always revert to their default properties. Interoperability lets Beans work anyplace where ActiveX objects or Live Objects can work. You could use a Bean with Visual Basic or in an OpenDoc container such as ClarisWorks. The bridging technology does practically all the work, so Bean authors have to write little or no code to get OLE and OpenDoc compatibility. JavaSoft already has some existing Java applets working with Visual Basic. Beans will lead to better Java development tools and will open up a lively market for prefab components. They'll also speed up Java's evolution, because third parties can create Beans that fill some of the gaps in Java's capabilities.  Inside Java Beans
Copyright 1994-1998 BYTE |