ver, several aspects of Vibe might make programmers think twice before using it.
Springs and Struts
The hallma
rk of Galaxy's GUI development system is its intelligent geometry management, which allows for smarter interfaces and is based on the concepts of
springs
and
struts
. Springs and struts, which
in Vibe
are a type of "connection," are logical entities that define orientation physics so that on-screen objects reposition themselves appropriately when the screen is resized or when an application designed on one platform is run on another platform.
During the development of the GUI portion of your application, when you place objects such as buttons or scroll bars on-screen, you can define a connection between the edge of an object and the edge of the frame or between opposite edges of an object. Connections between an object and the frame control the object's position. Connections between opposite edges of an object control the object's size.
Each of Vibe's four connection types -- struts, springs, spring/strut, and natural length -- has a specific behavior. A strut sp
ecifies a fixed value. If you put a strut between opposite edges of, say, a button, the button size remains fixed regardless of what happens on the screen. A spring expands and contracts as the user resizes the window, thus allowing objects to move while maintaining relative positioning. A spring/strut is a spring with a fixed minimum length. The natural-length connection enables an object to resize itself based on its contents. (For example, if you change the font size in a button at run time, the button resizes itself appropriately.)
Visix could have coded the intelligence of its scroll bars and buttons inside huge class files written entirely in Java, but then applications would be big and slow. Instead, Visix moved some of that intelligence into native classes that are actually part of the Vibe virtual machine (VM). Because they're native, they run faster. But they also require a nonstandard VM.
A Profundity of Files
A Vibe application has more than just a set of class files running i
nside a Java VM (JVM). Vibe has class files, .vibe files, a special Vibe JVM, and a "vibe runner" file. Every Vibe application you build creates an associated .vibe file, which is roughly analogous to the resource fork of a Mac application. In particular, the .vibe file carries the geometric information associated with the GUI portion of the application -- that is, inside the .vibe file is persistent data that describes not only what objects (e.g., buttons and scroll bars) are on-screen, but their position, too.
The .vibe file also contains the complete compiled version of the application. Hence, you can set up a Vibe application so that users can double-click on the .vibe file and launch the application as though it were a stand-alone executable.
This is where the runner file comes in. The Vibe runner, which must be installed on end users' desktops, consists of the Vibe JVM and native class files bundled into a single package. In the above scenario, when the user double-clicks on the .vibe file c
ontaining the application, it's actually the Vibe runner file that wakes up and begins execution. Note that the Vibe runner file is most useful for applications deployed through the enterprise. It's less useful for applications run on the Internet, where you can't be sure that a client will have the Vibe runner file.
Visix's use of the runner file offers some benefits. I've seen Java GUI-development systems that attempt to embed information about the visual components of an application directly in the Java source code, surrounded by comments and messages such as, "Don't edit this!" This information is embedded in the file because the integrated development environment (IDE) itself needs that data to create a design-time view of the application's GUI.
Vibe's approach, because it doesn't insert information into your source code, eliminates worries of accidentally editing a forbidden portion of source code. But, with all these special files to keep straight, distributing a Vibe application can be pro
blematic: You can't just bundle an application into a class file and ship that to a client.
Fortunately, Vibe comes with InstallShield, plus InstallShield scripts. These tools will help you by automating the construction of a distributable application bundle.
Bad Vibes About Safety
On the darker side, some of Vibe's admitted security holes are a wee bit disturbing. I am aware of two of them. First, the Vibe JVM does not perform all the verifications done by a standard JVM when a Java class file is loaded. The JVM specification describes four passes that take place when a class file is loaded. One pass verifies (among other things) that no local variables are accessed prior to being stored with valid values. The Vibe JVM doesn't do this check; it must depend on the compiler to do it.
If the compiler hasn't done this check, then the Vibe JVM is susceptible to whatever maladies might occur if the program attempts to manipulate an unorthodox value. (I should point out that the Vibe comp
iler does do these checks. Still, that's little help if someone tries to bring in an application from the outside.)
Second, the Vibe JVM does not include a security manager that restricts access to the network or file system. That means that if you have installed the Vibe JVM in your browser, a Vibe application (applet, really) downloaded over the network has full access to your machine. The Vibe documentation is succinct about this: "Basically, a Vibe application can do anything on your computer which a native application can do." Ouch.
Good Vibes
Vibe's springs-and-struts paradigm is a welcome mechanism for managing the GUI portion of an application. The .vibe file, while somewhat nonstandard, is certainly a step in the right direction for handling the sticky problem of where to put resource information.
However, too much of Vibe is nonstandard. The .vibe file is nonstandard. The Vibe JVM is nonstandard. The runner file is nonstandard. The reasons for all these nonstandard entitie
s are easy to see, but Vibe sacrifices portability to bring them about. Perhaps these problems will be addressed in future releases.
Product Information
ObjectSpace, Inc.
Dallas, TX
Phone: 972-934-2496
Internet:
http://www.objectspace.com