Ilog's JViews

   
SideBar
Short Line   MugMugMug
Version Reviewed: 2.0
Current Version: 2.0

Cup rating system:
4 Outstanding
3 Good
2 Acceptable
1 Poor


Vendor Info
ILOG, Inc.
1080 Linda Vista Ave.
Mountain View, CA 94043
800.367.4564
www.ilog.com

Product Review Product Review

JAVA'S ADVANTAGES IN designing applet user interfaces has earmarked it increasingly for use in two-dimensional data plotting. With this in mind, ILOG has developed JViews as a port of its longstanding C++ Views package. The company has long pioneered libraries that offer graphics and vector wizardry. The idea is to provide functionality for handling map and graph data, prototyping arrangements of graphics in precise form, and binding to underlying data. This is presented to Java developers as a system of class libraries that integrate into the existing AWT.

Unlike most class packages of its nature that provide rich display of tabular data, JViews is more concerned with the arrangement and viewing of complex data—primarily maps and node graphs with heavy interrelations. Each package bears numerous sorting algorithms and utility classes derived from academic lecture halls. ILOG classifies its package into three layers, ascending from the AWT foundation: graphic behavior and viewability, "manager" objects for handling dynamic views on visual data, and a grapher for defining and manipulating relationships among "nodes."

ILOG JViews installs easily as a zipped class file and has no user interface of its own. It is designed purely to be an API with binary class libraries. There is one utility, ILVEdit, for visually editing the auxiliary ".ILV" files JViews uses to store imaging coordinate information.

Image 1

Using the JViews graph layout algorithms, nodes can be arranged randomly (left) or in compounded geometric structures (right).

As typical with the newer breed of Java third-party APIs, the documentation and reference was meager and unable to fully define each class's place and ideal use in a non-trivial scenario. Luckily, the example demonstration applets were well-written and yielded more insight into using multiple JViews classes together over an AWT canvas.

The first level examined was the Graphic Viewing classes. This required setting up a GraphicBag instance into which graphics can be placed, dynamically zoomed and resized, and bound to user-defined properties. The GraphicBag bears no resemblance to the infamous GridBagLayout class from AWT but rather carries its own rich coordinate system. The main goal of the JViews Manager objects is to store abstract relational metrics for each item placed. In this fashion, the actual display can be set to different zoom levels and objects manipulated in more convenient relational ways than simply changing their hard-wired coordinates. Such operations include shrinking objects on the fly, retrieving the smallest "bounding box" around an arbitrarily shaped image, and rotating the object.

The cartography libraries for JViews are easily the most advanced in the package, and tailored for anyone who wishes to handle dynamic Geographical Imaging Systems (GIS) data in a more thread-safe language like Java. Maps handled in JViews can be raster- or vector-based and imported from many of the industry standard formats (e.g., OGDI, CADRG, DXF, SHAPE, DTED).

The JViews representation of map data extends all the way to the basic point, line, polygon, and vector information. This grants the developer the ability to perform all of the standard zoom, add, and change operations on existing maps generated by other applications. The JViews map package includes operations to render the map data in many projections (e.g., cylindrical, conic, planar) once the underlying vector data is instantiated. When used in tandem with the Manager classes, each component of map data can be assigned its own listener to filter incoming thread events. Using this functionality, it is possible to restrict "redrawing" to only designated areas when data is updated.

In keeping with the current trends in object-oriented technology, JViews includes components for binding graphic objects to business logic. These templates, designated as "prototypes" by ILOG, are roughly akin to the C++ template classes except bound to visual coordinate/polygon structures created by the developer. It was extremely easy to create simple geometric designs with the aforementioned ILV Editor, but alas, near impossible to do anything non-trivial. This was perhaps the biggest disappointment with any one aspect of the current JViews bundle. The utility had a very arcane interface, and the documentation included was not enough to demystify the advanced techniques needed to create graph plots. It also claimed to be capable of generating ILV files from standard .gif images, but this was impossible to actually carry to fruition. It would be really nice to have a simple method of importing graphics into the editor and generating coordinate plots and geometric logic rules from this.

Image 2

Intricate geometric shapes with logical properties can be created from scratch using JViews' ILV Editor and prototyping libraries.

In addition to the mapping and prototyping classes, JViews also provides extensive methods for laying out items in graph representation. This use of the term "graph" refers to the computer science definition of arbitrarily arranged and interconnected nodes in space, not the business charts and spreadsheet views generally connotated by the word. The most common uses of abstract graphs are to represent tree structures and node topologies (particularly electrical wiring and network layout). The implementation is fairly straightforward: once a graph has been declared with the grapher and its nodes added to the data structure, it can be laid out manually (i.e., explicitly placing each node at a certain point) or automatically (employing included or newly defined algorithms). Among the predefined algorithms are many optimizations of classic mathematical forms, such as Topological Mesh, Spring Embedder, and Uniform Length Edges.

Most of JViews' limitations are confined to usability quirks. A lot of its old-school "C++ visual library" feel is still present, resulting in many high learning curves and tedious processes to completing tasks. Nonetheless, these are tasks that would be even more tedious—if not entirely impossible—without JViews. While easily clinching its status as a forerunner in map and graph plotting, JViews will meet with competition in the area of business prototyping if it is not able to improve the versatility of importing and designing usable graphics. Because JViews is essentially a port from C++—an environment where there is no de facto visual layout standard—it will probably take a few subsequent releases for it to integrate more clearly with existing AWT and Bean technology. The JViews classes can be "beanified" manually for use in Visual Java IDEs, but this should be a more automatic process.

As it currently stands, JViews excels at what it does without getting in the way of other technologies a developer might wish to integrate concurrently in a large development path. However, its feature-set might be overkill if you're not specifically looking for Web-based GIS, interactive data-driven animations, or node graphing solutions. There are simpler and cheaper methods for the very basic layout and data binding, many of which are part of the improved JDK 2.0, but they may prove insufficient and inefficient for large-scale projects. JViews is certainly in a leading position to encourage high-end 2D developers (who have no doubt been eyeing Java curiously for a long time) to take the plunge.

Todd C. Zino works in publications and development at National Software Testing Laboratories. In addition to reviewing various object-oriented development tools, he is involved with programming and testing of network environments. He can be contacted at [email protected].