JUNGWiki

Introduction

We (the JUNG Development Team) like to think that we've learned a lot about what makes a good Java API for graphs and networks since we first created JUNG: from using it, adding new capabilities, fixing bugs, maintaining it, and of course from user feedback. So we wanted to use what we've learned to make JUNG better--and we have made a number of improvements along the way. Unfortunately, some of the design decisions that were made in the first version have resulted in problems that can't be resolved without a redesign. So we've been working on creating a new version of JUNG based on taking a fresh look at many of our original design decisions. It will not be backwards compatible with version 1.x code. However, we intend for JUNG 2.x code to retain much of the original 'feel' of JUNG 1.x, and we plan to provide both a guide to porting 1.x code to 2.x, and hopefully some "glue" that will make the porting process easier.

This page is devoted to a high-level description of version 2.0: goals, major changes, etc. You are welcome to add comments to this page, although we reserve the right to edit them or move them elsewhere. Please do not delete any text on this page unless you're a member of the development team.

Goals

When you get down to it, the list of goals that we have is pretty short. We basically want to make JUNG code smaller, faster, and easier to write and maintain.

Reduced Computational Overhead

Programming in Java involves a certain amount of overhead. Despite that, we have managed to write a framework that supports the creation and analysis of much larger networks than are supported by some other popular network analysis tools. However, there's a lot of room for improvement, and we've figured out ways to significantly reduce the overhead for typical graph implementations, without damaging JUNG's basic capabilities. The net result should be smaller, faster code.

Increased Simplicity of Use

We've spent a lot of time on the design of the basic interfaces and classes...perhaps too much. :) This has been a joint project, with a slowly changing cast of developers, and we haven't all used the same conventions throughout; this has resulted in a profusion of packages and interfaces and methods and capabilities. This has made JUNG a very powerful tool, but also sometimes rather confusing--especially if you need to extend JUNG to do what you want. So we've instituted a number of changes that should significantly reduce the complexity of getting off the ground, and make it easier to get full use out of the library.

Major Changes

The following list is not guaranteed to be either complete or correct; we may add items to this list, alter them, or remove them if our prototypes don't work out as well as we'd hoped. That said, anything that's here should be fairly dependable.

Generics

The generics capabilities of Java 1.5/5.0 have unlocked a lot of doors for Java code everywhere, and especially libraries like JUNG. They enable compile-time typechecking in places that it wasn't possible before (e.g., you can now know that you have a Set of vertices rather than of edges, or something else entirely), but that's just the beginning. Starting in JUNG 2.0, you will specify at the time of creating your graph what types of vertices and edges it will accept as elements.

In a related change, the responsibility for maintaining the relationships between vertex and edge objects now rests with the graph instance, rather than the vertices and edges themselves. This means that (a) vertices and edges can be of whatever type is desired, i.e., JUNG doesn't require any contract of them, and (b) vertices/edges can be members of > 1 graph. This vastly simplifies the process of creating subgraphs and other derived graphs (e.g. copies), and reduces the required space as well. Also, it eliminates the problem of having to ensure that your vertex and edge classes are compatible with one another and/or with your graph class.

Decorators, User Data Repository

JUNG permits at least three different ways of handling metadata: user-created instance and class variables, the user data repository, and separate components such as StringLabeller?.

At the moment, in order to create your own instance and class variables, olling your own decorations via will become much easier to use due to the changes noted above (since vertices and edges don't have to

The current design of the user data repository (in conjunction with other design decisions such as establishing vertex/edge equality via copying) has a lot of overhead and complication. It will either be eliminated or refactored into a more efficient separate class (which will only add overhead when it's used).

We are using generics to reduce the number of special-purpose classes and interfaces used for handling decorations.

Finally--since vertices and edges can now be any object--if your decorations are guaranteed to be unique, you can use the decoration itself as the object. For example, your code might look something like this:

    Graph<String,Object> graph = new UndirectedSparseGraph?<String,Object>();
    List<String> = getNames();
    // for each name in your list of unique names, add it as a vertex to the graph
    for (String name : name_list)
        graph.addVertex(name);

Algorithm Architectural Overhaul

In part because of some decisions of how most of JUNG's algorithms handle metadata such as edge weights, some of JUNG's algorithms are confusing to new users and sometimes hard to use even for more experienced users. In line with the redesign of the element decoration system, we are refactoring JUNG's algorithms to use a common (hopefully much smaller) set of interfaces for accessing metadata.

JUNG

Stuff from Other Places