The Artima Developer Community
Sponsored Link

Cool Tools and Other Stuff
JavaOne 2005, Day 3: Share the News!
by Eric Armstrong
June 30, 2005
Distributed development is a way of life anymore, especially for an open source project. But remote collaboration has been an essentially unsolved problem, most notably when it comes to specification and design. The upcoming release of NetBeans promises to tackle that problem in a very big way--and you'll benefit, even if you don't use NetBeans.


They're saying that the upcoming NetBeans 4.1 is not your father's NetBeans. So far, that assessment looks to be dead on target. There are plenty of new features to write about, including a better layout manager, a GUI design tool, ANT-based builds, and great tools for testing and debugging server-side apps as well as client apps.

The guiding principle in all this appears to be "things just work". The tools are doing all the complicated wiring and keeping it hidden behind the walls, so you can focus your attention on the problem you're trying to solve.

One of the major advances along those lines is the ability to collaborate with remote developers from within the NetBeans session, from a standalone tool that will part of the release, or eventually, from your favorite IDE --because it will be collab-enabled using the brilliant API standard and implementation libraries the collaboration project is providing.

The presentation on all these wonderful new tools was given by Todd Fast. But before I get to the details of the technology, let me motivate the discussion with a little story. That's in the next section. (You can skip if it you want to go directly to the main course and never mind the entree, thank you very much.) In outline, the story and the ensuing article go pretty much like this:


  • How I Came to be Interested in Collaboration

  • Introducing the Distributed Collaboration Project

  • Demonstration of Features

    • File Sharing
    • Code-Aware Chat
    • Public (persistent) Conversations
  • Collaboration-Enabling an App (Building a Collablet)

  • Immediate Uses

  • Future Uses

  • Conclusion

  • Resources

How I Came to be Interested in Collaboration

One of the great privileges of my life was to have spent time working with Doug Englebart-- father of the mouse, workstations, windows, outliners, links, and practically everything we take for granted in the computer world these days, with the possbile exception of the Internet. In 2000, I was lucky enough to find out about a colloquium Doug was running called "The Unfinished Revolution". Since I was live and work just down the road from Stanford, it didn't take much arm twisting to get me up there for the weekly sessions.

Talk about intellectual stimulation! Every week, my head was spinning with concepts and ideas. The event reawakened my original purpose in working with computers--to figure out how to use them to make a better world. Doug's purpose was nearly identical: To use them to help solve's mankind's most complex problems. (For more information on Doug's work, visit

When the colloquium started up a mailing list, I was all over it. After several weeks, it turns out that I was responsible for 50% of the traffic on the list. (And that was just message count. Thank goodness they weren't doing a word count...) I'm proud to say that I wound up giving a talk at that event, and that I was invited to talk at the wrap-up session, as well. It was a great way to share my concepts about we could be, and should be, doing to solve the problems mankind faces--hopefully, before they overwhem us.

When the colloquium ended, a group of us started meeting with Doug once a week to see if we could build something we could use to get started. You see, there were people all over the world listening in to Doug's sessions, who wanted to contribute. The problem was, we had no good vehicle for distributed collaboration! We needed a tool we could use to design solutions to problems, and the first thing we needed to design was the tool!

We met once a week for close to two years, but the problem seemed to metaphorize from week to week, and there were enough different agendas among the participants that we never succeeded in really defining the problem, much less specifying a solution. (In my mind, the issue was clear. But the issue was equally clear to everyone else--but different.)

One of the good things to come out of that series of meetings, however, was a non-profit organization devoted to studying the problem of distributed collaboration. The effort, dubbed BlueOxen, was started by Eugene Kim and Chris Dent, and featured no less than Douglas Engelbart on its Advisory Board. (For more, go to

There have many good discussions on the BlueOxen list on collaboration problems, and the group has sponsored several studies of best practices and methods. The group has developed some good software as, well, including some server-side implementations that help you put Engelbart-inspired "purple numbers" on a page. (Small purple numbers at the end of a paragraph that link to the start of the paragraph, so you can easily reference any part of the page by copying it's link.)

As always, though, the chicken and egg problem of distributed collaboration remained: How can you allow remotely distributed people to collaborate well enough to design and build a distributed collaboration engine? Lacking the tool they needed to build the tool they needed, progress was necessarily limited.

The basic tool needed to solve the problem may just have been demonstrated today at JavaOne, however. In part, it's a distributed collaboration tool that has a standalone implementation and a NetBeans implementation. But more importantly, consists of both a specification that allows remote, heterogenous systems to work together seamlessly, as well as an underlying system that makes it almost simple to enable collaboration for almost any software you write.

Introducing the Distributed Collaboration Project

This section introduces the terminology and describe the demonstration, showing how the technology is currently being used. Subsequent sections describe the demonstration of implemented features and show how the technology works.

Like any good modern-day development effort, the NetBeans collaboration-tool project starts by defining the ontologoy for the domain--the collection of terms and concepts that define the problem space:

A conversation consists of multiple participants who are communicating using one or more channels, where a channel is, for example, a whiteboard, a vocal exchange, or __xx__.

That's pretty much all that a user needs to know to decipher the terms in the interface. For developers, there are a few more terms to introduce-- the ones that define the solution space:

Each channel is implemented by in a collablet --a class that implements the tiny little Collablet interface. The collablet registers itself with the application, so it is notified when things changes. It then uses a CollabBean to send messages to participants, and to receive them.

The implementation library includes CollabBeans that send and receive XML messages to participants using MOXC--the Message-Oriented XML Collaboration protocol. Other CollabBeans can be implemented as well --for example a Voice Over Internet Protocol (VOIP) bean to handle voice traffic.


  • Current implementations include NetBeans 4.1 and CodePal, a standalone tool.
  • The container (NetBeans or CollabPal, at the moment) handles the work of sending messags and tracking participants. The collablet you write for an application really only cares about the content of the messages.
  • Because that message protocol is XML-based, collaboration tools can interact on heterogenous systems.
  • Because the design is message-based, with no code sharing, it keeps things simple. Particpants are easily added and removed.

Demonstration of Features

This section describes the implemented features that Todd Fast demonstrated. The next section goes under the hood to describe how the technology works.

This section covers:

  • File Sharing
  • Code-aware chat
  • Public (persistent) Conversations

File Sharing

Dragging files, directories, or entire projects into the file sharing window makes them available to everyone. Each participant gets a copy of the file, so they're editing locally instead of remotely. While they're editing, the file is locked. It can be read, but not written.

Remote particpants can also build the system. The build occurs on the originating system , so that system needs to be fast, and the participants will have to talk to each other.

You can drag shared files onto the local system to do your own local builds, but in that case you'll have to drag the modified versions back into the system to share the changes. Also, the system it isn't integrated with a source control system. (It's not perfect. But it's taking a major step down the right road. More importantly, it's providing the basic tools we need to build bigger and better systems.)

Code-Aware Chat

The chat window automatically recognizes Java code, HTML, and a variety of other languuages. So it does syntax highlighting and peforms code-completion, for example, so you can either paste existing code or write new code in the chat window.

The system also adds line numbers so you can talk about line 46, for example, instead of having to say "the 2nd if-statment in the hoozit method".

Public (persistent) Conversations

Although it wasn't demonstrated, the NetBeans implementation also has the capacity to define a public conversation--one that is persisted on the server, where it is available for others to examine.

The system makes it possible for designated participants to carry on the discussion. For others, it's read-only. They can monitor the conversation, but can't participate.

Collaboration-Enabling an App (Building a Collablet)

Todd Fast showed how to collab-enable an existing application with a simple little program that tracks mouse clicks with a colored spot. The program let you change the color of the spot (a large circle), and put it whereever you clicked the mouse.

The process was completed in fours steps, with no more than a few lines of code in any step. (As the number of possible messages grows, the line count will go up--but all of the additions will be related to the application. All the overhead you need will have been added with those few lines of code.)

The process looks like this.

  1. Register property-change listeners and send property-change messages.

    That requires two simple methods in the application, on to register listeners, and one to notify them when something changes. (For some applications, the hardest part of the process will be "instrumenting" the app to notify listeners whenever something changes.)

  2. Define a unique namespace to use in the XML messages.

    Define a string constant (final String) for that purpose. It could be anything, but generally it's defined as the project host's URL, along with the project name. So it would be something like this:

  3. Send a MOXC notification:

    Document doc = createDocument(); // create an XML document

    Element element = doc.createElementNS(NAMESPACE, "spot:colorSpot);

    element.setAttribute("color", spotPanel.getColor(color)); // an integer


    Note: I didn't get the code that obtained the spot's color, but it's the simple, standard spot.getColor() kind of thing.

  4. Receive a MOCX notification:

    Element element = message.getMessageElement();

    if (element.getLocalName().equals("colorSpot") {

    Color color = new Color(getIntegerAttribute(element, "color");



    else if (element.getLocalName().equals("something else") {



There are undoubtedly some errors in my transcription. But you get the idea. It's absurdly simple to collab-enable an application. The API libraries does the work of notifying all of the participants in the conversation. The shell you're working in (NetBeans or the standalone CollabPal) keeps track of who's participating. All that wiring is kept behind the walls where it belongs. All it takes is a few lines of additional code, and you're in business.

That simplicity, coupled with the basic losely-coupled, XML message-based design, is why I called the APIs "brilliant", and why I'm waxing so enthusiastic about it.

Immediate Uses

These are the things that the NetBeans solution enables today:

  • Code Sharing and Development. This is the obvious use case, and it just became reasonably possible.
  • Support. The automatically-generated line numbers on code segments will make it easier to talk about things.
  • Specification and Design. This where the biggest impact will be, in my opinion. The ability to work collaboratively on use-case documents and design documents may make it possible, practically for the first time ever, for remote people to design together, in addition to working on a shared code base.

Future Uses

Here are some other things that the APIs make possible:

  • Better webLogging tools.
  • Threaded discussions that lead somewhere.

Better WebLogging Tools

A server-based weblogging like the one provided at Artima has the advantage that you can access it from anywhere--which turns out to be pretty convenient when you're covering a convention like this.

On the other hand, if a session times out you lose your recent work. That's somewhat less convenient. With this API, a simple editor could be collab-enabled, and possbily delivered with Java Web Start. Voila! A real editor that runs anywhere, with a simple Ctrl-S command to save work in progress to the server.

Threaded Discussions that Lead Somewhere

Email discussions reach their conclusions down at the bottom of the thread, somewhere. That makes them hard to find. What you really want is for the decisions to propogate to the top of the thread list, with a pointer back to the discussion that got you there. (For more on that subject, see What's Wrong with Email? at

The need to repeat parts of a message to comment on them creates redundancy. What's really needed is a 3-dimensional hierarchy, with the original author's outline in the 2-dimensional plane on screen, and a hierarchy of comments extended into the 3rd dimension.

Weblogs provide a communication channel that solves some of email's problems, but it's essentially one-way. People can comment, but it's hard to have a real discussion.

The collaboration APIs raise the interesting possibility of using a discussion management tool that helps a facilitor keep track of a discussion (such as the tool developed by Jeff Conklin at the CogNexus Institute, By collab-enabling such a tool, peoiple involved in a remote conversation can carry on their discussion within the context of a tool that tracks the results.


Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Eric Armstrong adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at Eric is also involved in efforts to design knowledge-based collaboration systems.

This weblog entry is Copyright © 2005 Eric Armstrong. All rights reserved.

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use