Java Beans: solving the authoring grind

Emedia Professional, Feb, 1998 by Kathy Kozel

Java will eventually touch--and probably change--the life of every new media author. We can go quietly, or we can do it the kicking-and-screaming way. Or, we can look at Java the way we first looked at digital video. Of course it looked awful, but you knew it would change everything. And even in its primitive state, digital video was making an impact right from the start.

But what does Java really mean for new media authors today? For one thing, Java offers a standard for output of not only media files, as we have now, but actual interactive programs. It's a standard which is cross-platform without going through any porting, rewriting, exporting, modifying, or gaffing. With Java, you build your interactive multimedia program using one of the many Java authoring or programming tools, then save it as a set of Class (.class) files. These exact same Class files will play back on any computer running the Java Virtual Machine (JVM), a piece of software that runs on top of a computer's own operating system. It's as though there were only one kind of computer in the world--the JVM--and you're writing for it.

THE BEAN SCENE

Besides cross-platform bliss, Java's most compelling feature may be its object-oriented architecture. Java lets developers bundle pieces of code into little self-contained, reusable building blocks, and Sun has a standard format for bundling components called Beans. But although software engineers have been talking about components for twenty years or more, no programming construct has been able to support it in such a pure, easy-to-build-and-use way.

A Bean is nothing more than a little code which appears to authors and programmers as something like a "black box." If a Bean is written correctly (adhering to the Bean format), then the author doesn't need to know or care what's inside. The only thing the author cares about are the events the Bean can be triggered by, and how the Bean will respond. What it listens for, and what it does. For example, if I have a pie chart Bean I want to use in my program, I need to know how to feed the Bean, which in this case is how to give it the stats for the chart. I also need to know what the Bean will do with the numbers, which may be, for instance, what kind of chart it will draw and where it will draw it.

The coolest thing about Java for both non-programmer authors and hard-core coders alike, is how simple it is to use Beans in sophisticated ways. Using any program that supports Beans, you usually just click on the Bean to get a list of event choices (such as mouse Up, mouseDown, keyPress, and startBean) and then you can choose the action to take as a result (drawTheChart, setTheText, or animateYourself). Within a year--probably less--virtually every Java authoring tool and some existing currently-non-Java authoring tools should be supporting the use of Beans, and those which hope to survive will also support the creation of Beans.

Sun already has a sample BeanBox where you bring Beans in and by dragging and dropping construct a complex interactive program. Developers familiar with other drag-and-drop or choose-from-a-menu authoring tools may wonder what the big deal is. But with non-Java tools you're always working with proprietary components, and to extend the authoring tool you usually need a "real" programmer working in a difficult environment.

But authors and programmers alike can build Beans in any number of tools, and use them in a completely different tool. The Bean-builder doesn't have to know about year authoring tool, and the Bean-user doesn't have to know how or where the Bean was built! That's an almost utopian ideal and Java has brought it so close I can already smell it brewing.

JAVA PHYSICS: IT'S ALL RELATIVE

The most common complaint about Java regards playback speed. And in this case, Java's critics are often right. You probably won't build that blazingly fast shoot-em-up in Java--for now--but you won't build it in any other authoring tool either. But for the majority of what multimedia authors build, the difference between C and Java makes no difference. If the title isn't supposed to run that fast, then you've lost nothing. Your final goal--what your program is supposed to do--is still achieved.

And although Java is still weak on the multimedia side, Sun is putting a tremendous effort into developing their new Java Media Layer, which also includes licensing best-of-breed from others, as they did with their Thomas Dolby/Headspace deal for audio. Early demonstrations of Java 2D, 3D, and Video are amazing.

Plenty of issues still remain unresolved, including whether Microsoft will succeed in making its own flavor of Java, which of course defeats Java's entire cross-platform purpose. Sun, on the other hand, is fighting hard for 100% Pure Java, which will guarantee portability. Authoring tool heavyweight Macromedia has signed on to the 100% Pure initiative, perhaps the most significant authoring tool news yet.

Coming "soon," Macromedia will support a Java export for Director, which will build true Java Class files from Lingo code. Macromedia does claim that the plug-in may perform better than the Java export, but it's still a monumental step. Imagine using your favorite authoring tool to develop full-blown, no-plug-in-required Java. And though there's been no official announcement, Macromedia engineers say they can build an import for Beans built by programmers and authors using other tools.