Corel Office for Java has much of what you'd expect from an office suite-but to customize it effectively, you need to understand JavaBeans, the component architecture at the heart of this all-Java application.
A primary worry of any IS department-regardless of size-is compatibility. You might have accounting running on AS/400s, marketing on Macintosh, engineering on UNIX, and everyone else on Windows. You figure you have just two chances for cross-platform compatibility-slim and none. Sure, everyone is on the same network, but what about the applications? By now you've grown weary of languages with the promise of cross-platform compatibility (who can forget UCSD Pascal, not to mention C?). Of course, this new Java thing might work, but it's years away.
Well, it's only months away if Corel has any say in the matter. Remember Corel? It bought WordPerfect and Quattro Pro, and has made a fairly strong showing in the Windows office suite market recently. It decided early on that Java would have a strong presence, and its developers have been rewriting WordPerfect, Quattro Pro, and the rest of its Office suite in Java. Not just any Java, either-Corel Office for Java is certified as 100% Pure Java by JavaSoft. Corel's intent is to let you run its Office on virtually any hardware you have.
Virtually is, of course, the operative word here. Before you can run Office for Java, you must have a Java Virtual Machine (JVM). However, that shouldn't be a problem-Sun has one for several platforms, and both Internet Explorer and Netscape have them built in. Most operating systems will include a Java Virtual Machine in the near future. The new Network Computers will have Java support built in as well, and Java will someday extend down to smart cards, personal digital assistants, and cellular phones.
While you can run Office for Java in stand-alone mode, it is designed to run on your intranet. The actual Java code (some 4,000+ class files in about 500 directories) can reside on either the server or a local hard drive, and might be split so that larger, less-used portions can be shared from the server. Document storage would primarily be on the server, although some Java Virtual Machines will offer local storage.
You're probably wondering what an office suite can do for software developers. Sure, it sounds like a neat office tool, but what can it do for you? More than you might think. To really understand the relevance, you need to understand JavaBeans, the component architecture at the heart of Corel Office for Java.
Unlike Java applets, Java Beans do not need to run inside a browser, nor are they stand-alone executables, like applications. Rather, Java Beans are the components that make up applets or applications. Connecting Java Beans to one another-subclassing and extending functionality between the buttons à la Microsoft Office VBX and OCX custom controls-will be fundamental to JavaBeans-enabled applications like Corel Office. One of the main features of Glasgow, JavaSoft's internal product name for the next update to the Java-Beans technology (due sometime around the end of 1997) will be the Extensible Runtime containment model, which provides a method for hierarchically grouping Java Beans. The Java version of the component container will be able to dynamically add and remove individual Beans as well as mark a subset of them as a selection. Before delving deeper into the ins and outs of Java Beans, let's look a little closer at the suite as a whole.
A Sweet Suite
Corel Office for Java has about everything you might expect in an office suite. This includes word processing, spreadsheet, charting, presentation, and drawing components to create compound documents. WordPerfect handles the normal document needs, augmented by Quattro Pro for spreadsheets and CorelCHART for charting. Corel Presentations takes care of the business graphics, and InfoCentral acts as the phone book, scheduler, and e-mail program. Finally, Corel Desktop gives the applications and their files a tree-structured home.
WordPerfect has a devoted following, and Corel hopes it will continue into the Internet. WordPerfect for Java is a bit of a change, not in the least due to the limitations of Java. It manages to show an adequate toolbar, but the menus are hidden until you click a toolbar icon. However, WordPerfect for Java is still a formidable word processor, supporting fonts, tabs, bullets, and columns.
Corel Presentations produces standard business graphics and can create a run-time slide show that will play on computers that don't have it installed. Drawing tools are included for basic shapes (rectangle, square, circle, ellipse, and line). Ad-vanced tools include polygon, star, Bezier curves, and several gradient fills.
InfoCentral rounds out the suite by providing a place to keep your addresses, schedules, and e-mail. The address applet is flexible, supporting separate address books for groups and individuals. The calendar applet provides group scheduling and features a drag-and-drop interface. The e-mail component is very powerful-supporting all the major standards (SMTP, POP3, MIME, UUencode, and more). The included calculator is a nice touch, but it has interface problems.
The desktop is part desktop and part file manager. You can organize your files using a tree structure, and add shortcuts to the desktop using drag and drop. It's a far cry from Windows 95, but at least it achieves a common user interface on all platforms.
The main problem with Office for Java is that the applications are not full-featured. If you're expecting direct ports of the latest WordPerfect or Quattro Pro, you're in for a disappointment. The basic functionality is there, but many things you might want are either not possible in a cross-platform environment or just were not ported to Java. Embedded OLE objects, such as Visio charts or Corel drawings, require a native Windows application. This will change as vendors create add-in components, but it will take time, strategic agreements, and a shared vision.
You Use It, It Uses You
Office for Java can benefit developers from two directions: embedding it within your own intranet programs, or embedding your functionality within Office for Java. Looking inward from your enterprise, you will find that you can embed Office for Java in your own intranet programs. Much like custom controls in the Windows environment, you can drop these components into your Java applications. This is possible because all Office for Java components are fully Java Beans-compatible.
Java Beans, as mentioned earlier, are the equivalent of Windows VBX and OCX controls. They have properties-variables you can read or change. They have methods, which are essentially routines that you call. Finally, they have events-places you can add your code to respond to system or user-generated events. In the area of properties, methods, and events, Java Beans are very similar to Windows custom controls, and should be just as easy to use. Thanks to the JavaBeans architecture, developers using Office for Java will be able to add entire components or individual features, tailoring the suite to their specific needs. To understand how you'll be able to do that, let's look a little closer at some JavaBeans basics.
The most basic thing you need to do is make sure you're using the right vocabulary. The one-word term, Java-Beans, is used to refer to the specification; while Java Beans (two words, or Beans for short) refer to the implementations of the specification. Beans can vary in size and complexity, from simple GUI elements such as buttons to full-scale applications such as the Office for Java components. Beans can also act as containers for other Beans.
To connect Beans to one another, the Java Design Tool you use-Visual J++, JBuilder, Visual Café, and so on-must have information about the Beans. This information includes the properties a target Java Bean exposes, the methods it lets other components call, and the events it fires. The process of acquiring this information is called introspection.
Via introspection, the Java Design Tool determines the properties of a Java Bean and creates a property sheet that lists these properties. More sophisticated design tools such as Visual J++, JBuilder, Visual Café, and so on also provide an editor for each property. A property editor is a class that lets you perform GUI editing on a property.
Information about methods is maybe the most important thing introspection can find in a Java Bean. Remote Method Invocation (RMI) is a feature that permits a Java program running on one Java Virtual Machine to invoke a method on a different Java Virtual Machine. The two Java Virtual Machines may be running as separate processes on the same computer, or may be running on different computers connected to a network. Once a design tool finds the methods, it can apply standard code naming patterns to their signatures. These patterns let the design tool determine which methods manage properties or source events, as well as which methods can be exposed to other Beans. Standard code patterns are conventional names and type signatures (get<name>, set<name>, and so forth) for sets of methods and interfaces that are used for standard purposes.
Versions of Java prior to 1.1 use an inheritance model of event processing. In the inheritance model, subclasses of the Component class can only handle events by overriding either the
action( ) or
handleEvent( ) method. Since events are delivered to components regardless of whether the components actually handle them, the inheritance model isn't the most efficient way to handle events. The logic to process different event types is complex and error-prone. In effect, programmers must write their own event handlers.
Under the delegation event model introduced in Java Development Kit 1.1, an event listener object is registered with an event source. When the event source detects that something of interest to the listener object has occurred, it creates an event object and calls an appropriate method in the listener object so it can pass the event object to the listener.
With a solid understanding of JavaBeans properties, methods, and events, you now should have the tools at your disposal to customize or change the appearance and behavior of Beans within Office for Java. Customization of Java Beans can occur in two ways, depending on their complexity. The first form of customization works well with simple to medium-sized Beans. The design tool you are using determines the properties of Java Beans and lets you directly edit property lists. The second form of customization uses customizers or wizards that will change the appearance of Beans as the user navigates through property lists. Customizers are most effective for large, complex Beans, like those within Office for Java.
In addition to letting external programs access components' exposed interfaces via introspection, Beans within Corel Office for Java will have other features. Using persistence, you will be able to save and reload Bean properties at design time-much like the way you can with Visual Basic's FRX files. Various utility Beans (adapters) will also be available from Corel, in addition to the main Office components, extending functionality to third-party Bean developers. Bridges to other component models such as Micro-soft's ActiveX, Netscape's Live Connect, and CI Lab's OpenDoc will make it possible for Beans within Office for Java to run in a wide range of environments. Finally, the customized Beans will have the capacity to be embedded into a package-a single source file containing all necessary files: both Java classes and ancillary files such as images or help files.
JavaBeans is different from other object models due to its design philosophy and history. Most existing component APIs were designed by scaling application-sized objects down to components. The JavaBeans API, on the other hand, was designed from the ground up to minimize complexity and use a smaller overhead. This resulted in Beans that are small enough to survive the trip through a narrow bandwidth pipe.
The JavaBeans philosophy is reflected throughout the design of Office for Java. Rather than the document residing in the application, the application resides in the document. Since the components are also containers, you can start with a spreadsheet and embed a letter, or vice versa. The main interface remains the same-only the available options change. This sounds a lot like Microsoft's OLE, but Corel's approach requires much less overhead than OLE and is available cross-platform. The framework is JavaBeans-compliant, enabling open and nonproprietary integration with third-party components.
You can also work from the bottom up by embedding your functionality within Office for Java. For example, you can add a custom math function to Quattro Pro, or an equation editor to WordPerfect. Assuming you write your extensions in pure Java, they will also be portable.
Unlike today's office suites that are centered around a "fat" client, Corel Office for Java is network-centric. This means all of the applications and components can reside on the server-downloaded transparently to the client as needed. As a result, maintenance is greatly simplified; upgrade the server copy and everyone is painlessly upgraded at once.
The network-centric approach can help create an ideal workgroup environment by letting users share any document without regard to file format or operating systems. In fact, it helps telecommuters and on-the-road workers remain closer to the office while away-all they need is a phone line and a browser to have full access to office files. Meanwhile, server-based version control keeps track of the changes and controls access rights.
Corel promises that a full Office for Java SDK will be available by the end of 1997. The kit will include full documentation and will be licensed to developers free of charge. The Bean Development Kit (available at www.javasoft.com) also has useful information for anyone who wants to use Office for Java components in their applications.
Will It Fly?
Well, that's the $64,000 question. Corel is making a bet that the Internet, and intranets, will invade every corner of the business world. And when they do, Corel will be there with a complete solution. But it won't happen today. And it might not happen this year.
I examined the first version of Corel for Java, downloaded from Corel's web site. This 9MB file installed to become 4,259 files in 518 directories. I was able to run most of it in both Netscape 3.0 and 4.0 (beta 5.0) and Internet Explorer 3.0 and 4.0 (beta 2.0); however, none ran perfectly. Sun's Hot Java browser got hung up while trying to open the WordPerfect component. When I attempted to run it within Asymmetrix's Supercede, I merely succeeded in crashing Supercede. No matter where I ran it, it ran slowly. I would have expected better performance than I found on a Pentium 133, and on a 486 it was atrocious. This first beta version has been out for months, and a second beta was expected by the time this review went to press, which should have helped. However, at press time, there was no word on when that update would be available.
Normally, public betas are feature-complete but buggy. Corel Office for Java is both buggy and incomplete. (Although it's not too buggy. Due to Java's "sandbox" nature, which imposes tight restrictions on downloaded code, I never crashed the browser or the operating system.) While Corel bills this as a first beta version, it feels more like a proof-of-concept or demonstration. Import filters are missing, but the release version will be able to import WordPerfect, Word, Quattro Pro, Lotus 1-2-3, and Excel files. The errata file included with the download was 10 pages long when printed. According to the errata, there are several large problems and plenty of small ones. Scroll bars, printing, and the clipboard interface all have problems. Some user interface components aren't rendered correctly in some browsers. Many more features are simply not yet implemented.
The biggest drawbacks of Corel Office are due more to the limits of Java than anything else. The ones that hit me the hardest were the lack of clipboard, printing capability, and local file saving. While file saving to the server will be supported at release, local saving will be dependent on the browser or Java Virtual Machine. In Windows programs, the clipboard would normally be a common method of transferring data between applications-I wonder if Corel assumes we won't be using other Windows programs? Finally, I wonder if people will be willing to take a feature cut to achieve cross-platform capability.
The comparison between Corel Office for Java and Microsoft Office 97 Developer Edition is similar to the apples vs. oranges comparison. While they may play to the same audience, the capabilities are far different. The individual components in Microsoft's Office are incredibly powerful and feature-laden, but they're only cross-platform when you're running Windows on an emulator. Corel's Office can run anywhere, but lacks many features users have come to expect in word processors and spreadsheets. Microsoft's Office is rather mature, and as of the 1997 version, all components share Visual Basic for Applications as the standard macro language. Corel's Office has no macro language yet, but it will be Java when it happens. Corel's Office also has no real database-at least not in Access's class.
It looks like this suite, though revolutionary, is still not quite there. It's a grand vision, and Corel is farther along the road than anyone else. In many ways, Corel is paving the road as it goes, and it ought to be a smooth one when it's finished.
Product Summary: Corel Office for Java (beta)
Fax: (613) 761-9176
Price: Not available at press time
Software/Hardware Requirements: It runs on any machine with a Java Virtual Machine.
Competitors: Microsoft Office 97, Lotus SmartSuite, Lotus Java-based business productivity software (beta code name: Kona)
1. It will run on any machine with a Java Virtual Machine.
2. It is fully network-centric.
3. It is implemented as Java Bean components.
1. It doesn't have the full feature set we're used to seeing in Windows applications.
2. Its execution is much slower than comparable platform-dependent programs.
3. There is limited interaction with the client system (especially with clipboard, printing, and local save).