JavaBeans: The Basics
This week, we're looking at another facet of the new Java: JavaBeans.Just to clarify, in case you're not actually programming yourself, writing code is all about drudgery. This is all the more so because programmers spend a large amount of their time repeating themselves or the work of their peers.
It would probably be a real embarrassment to the industry if we had to tally all the different times we've solved the same, dull problems: video drivers, interface routines, editor windows (which should be simple, right?), and so forth. All of which are written and rewritten, and then rewritten again, simply because we can't, or won't, incorporate other people's code into our own, and that's assuming we know about the opportunity in the first place. Or that's assuming that the code is flexible enough to be traded around without having to be extensively rewritten every time.
Anyone who claims to actually enjoy writing the same routine 10 slightly different ways, for 10 slightly different computers, is clearly in need of some vacation time. Eventually, not only programmers, but their employers as well, came to have a serious desire to stop the waste. There were lots of arguments for it: It would save hundreds of millions in duplicated effort industrywide; it could create a lucrative software components market; and it might promote standardization that would make computers easier to use for everyone.
So with everyone pushing to refine programming practices, what have we actually come up with? Believe it or not, the first higher level languages were an initial major step. Object-oriented languages were another of the most recent developments. Lately, component systems--like Apple's OpenDoc and ActiveX--have become the rage.
Their purpose, for the uninformed, is to allow not only programmers, but users as well, to quickly and easily mix and match various software components. Standards are set by which components are written and used, and the theory goes that if the standards are sufficiently flexible and forward-thinking, they can allow extensive and easy reuse of any number of commonly made and remade software pieces, without hampering new innovations in how this software is written and organized.
For its part, OpenDoc seems to be a far more complete system than Microsoft's offering--which is really just a retooled version of OLE, a system originally created for transplanting Excel spreadsheets into Word documents. Aside from predating it by a significant amount of time, it's somewhat more refined and generally more robust--by reputation, at least.
It was only natural for Java to enter the component system fray. Since the entire architecture is object oriented from the start, and since the platform independence of Java code would make it necessary to write the components only once, it's an ideal medium for this kind of endeavor. Always a sucker for bad puns, Sun called the system JavaBeans.
Sensibly enough, the best perceived approach in this kind of competition is a friendly one: All of the competitors are scrambling to make their system compatible at the component level with that of everyone else. Microsoft already moved to release their ActiveX system for the Macintosh and provide some support for Java. Apple has announced plans to incorporate Java directly into their OpenDoc system, and Sun, not even close to being outdone, has already made their system compatible with both, as well as Netscape LiveConnect system.
There are compelling arguments to go with Beans: The most obvious being the cross-platform nature of components written in the framework, and the robust programming environment. Not the least of which is that the system appears to be well designed and relatively easy to use for both Bean developers and users.
We'll have a lot to say about Beans in the coming weeks. For now, we can start by covering the basics. What does it really mean to be a component in a component architecture?
We've pointed out the most important feature--that Beans stops code wastage. Yet if you think about it, the concept can be exploited in any number of other ways as well. The Beans documentation clearly indicates Sun's intention to migrate a significant portion of existing API functionality into Beans, with the example they cite most often being the basic GUI building blocks of the AWT (buttons, lists, and the like).
However, Beans can encompass multiple classes, and the system is just as capable of carrying simple components such as interface objects as it is of vastly complicated components. Not only that, but it's quite conceivable for Beans to be interchangeable, not only during development, but at runtime, just as OpenDoc envisioned. Sun is already envisioning most of the same elusive dreams that Apple and Microsoft have shared--of users creating "meta-applications" of mixed-and-matched software components of their choosing.
The Java designers also very deliberately made a great number of accommodations for what we refer to as "visual development tools." Many readers will remember with a smirk how many different companies have chased this same nebulous goal: development environments where any layman could create an application just by repositioning icons on a screen. Some failures were worse than others, and few are still around.
No Java Jolt reader should suffer under the illusion that it's possible to really program without actually writing code, at least during this century, but there is something to be said for the approach, even it fell short of some of its more aggressive marketing claims.
Just as with the security model, implementing all the details of the Beans system in Java left us a number of useful spinoffs in the new Java API, from new (and arguably much needed) programmatic introspection, to object serialization and remote method invocation, not to mention the JDBC.
Don't worry, we'll be covering all these new and incomprehensible concepts in due time. In the mean time, dust off your Adobe Acrobat Reader and check out the JavaBeans paper. See you next week.
