Feature Story

Jackpot!

New project at Sun Labs promises to make programming tools more effective.

12.Nov.02--Michael Van De Vanter speaks in a surprised tone when talking about the state of software development. In a business renowned for innovation, the innovators' tools--the editing, compiling, and debugging software known as integrated development environments (IDEs) that are used to write source code--have bucked the trend. "IDEs have a lot of features, " says Van De Vanter, a principal investigator at Sun Microsystems Laboratories, "but the fundamental technologies--the compiler, the editor--really represent technology that was mature 20 years ago."

This oddity represented an opportunity for Van De Vanter and Java technology inventor Sun Fellow and vice president, Sun Labs, James Gosling, and for Senior Staff Engineers Tom Ball and Tim Prinzing who have researched and used developer tools for years. "There have been a lot of good ideas and interesting approaches that weren't being reflected in the commercially available tools, particularly the IDE interface," says Van De Vanter.

In July 2000, Van De Vanter and Gosling decided to combine forces on a new project called Jackpot. The project is all about making programming tools more productive by making them easier to use and more effective at reducing code complexity. To this undertaking Van De Vanter and Gosling brought an intimate appreciation of how programmers actually work, along with new architectural approaches.

"The opportunity we saw was to to take a fresh look at the world of IDEs and bring some of these ideas--some new, some old--about how to raise the bar, to make things better than just an accumulation of features."

They also brought a canny research methodology that is already paying off: a commitment to prototype Jackpot using the open source NetBeans platform. By taking their prototypes out of the lab and into the open source developer community for real world feedback, they have positioned their project for success. "We think our approach will be validated--and completed--by the developer community," says Van De Vanter.

Metrics Module

To date, Jackpot has yielded a metrics module and a program editor architecture that incorporates pluggable language-analysis components. A version of the metrics module prototype is available on the NetBeans platform. Created by Tom Ball, the metrics module analyzes source code using a set of configurable diagnostics. It then helps the programmer "drill down" to potential trouble spots. The metrics help produce better code by pointing at high maintenance areas that need programmer attention in order to produce code that is easier to maintain. Jackpot's metrics are calibrated to track code complexity, because there are known correlations between code complexity and the lifetime cost of code.

"The advantage is that you find problems sooner and that you ship code cleaner, so it will be cheaper to maintain," says Van De Vanter.

Metrics utilities, as Van De Vanter notes, have been around for years. "Source code metrics were traditionally the province of management and auditing tools," says Van De Vanter. "As a result, they tended to come somewhat later in the development cycle and have less impact back on the actual design of the code." This is a costly flaw.

"Experience shows that the earlier you get feedback, the better," says Van De Vanter. "It's widely understood in the software engineering community that the cost of changing something in a program increases exponentially during its lifetime. So when you are still developing, it takes a second. By the time you get to integration, it takes longer. By the time you ship the product, and it's actually in deployment, the cost of fixing something goes up enormously."

Ball sought to incorporate metrics into the developer's environment in ways that make it inviting to use. The key is integrating the metrics usefully into the process of writing source code. "The first thing you need is integration into the environment. So that it's just right there, with all of your other work. So that within the flow of the programmer, the metrics is just a natural part of it," says Ball.

When it comes to metrics analysis, the team acknowledges a caveat: that metrics are more like guidelines than hard science. In a world where software systems have become larger, more complex, more concurrent, more distributed, and more dependent on other people and software, it's not always possible to write simple code. Accordingly, the metrics module allows programmers to adjust thresholds, set audit levels, and even to turn off diagnostics when needed. These overrides "cut down on the bother factor," says Van De Vanter. And that makes programmers more likely to actually use it.

Specialized Editors

The Jackpot project has also produced an experimental code processor with an architecture that allows programmers to plug in specialized editors. The specialized editors are for the variety of languages found in most source code: the machine language of the code itself, the human language of comments, the typographical lexicon of white space, and the highly-specific syntaxes of data such as strings or embedded HTML.

"The approach we're taking is an architectural one," says Van De Vanter. "Tim Prinzing [author of the Swing Text Framework] is creating a code editor architecture that supports dynamic creation of specialized editors for pieces of the code, on demand, as you're editing."

The specialized editors use language-analysis to interactively turn themselves on and off. For example, when the programmer's cursor moves over a comment in the code, a human language comment editor is enabled. As programmers move about the program, other editors are activated for data, strings, or chunks of embedded HTML. This approach may permit Gosling to implement a personal quest: a specialized editor for mathematical code. The idea is to use language analysis and typography to present the text in visually appropriate ways that make it more readable and easier to understand.

"Twenty years ago people were using plain text editors such as vi and EMACS for both code and natural language documents," says Van De Vanter. "Now almost no one uses vi or EMACs for natural language documents. They use Word, or FrameMaker, or the Star Office software, because it's been specialized for natural language processing and uses the power of visual feedback in ways that are specialized for natural language documents. It's the WYSIWYG approach pioneered at Xerox PARC. That process of specialization has not taken place in the area of code editing. The fundamental editing part of it, what you type and what it shows you, hasn' t really changed in over 20 years."

Jackpot's specialized code editors would not only bring a WYSIWYG approach to viewing source code, but also an extensible set of utilities that would aid in a variety of programmer tasks. Among them, "refactoring," the updating, adapting, and porting that is the fate of most source code over its useful lifetime.

Also at the prototype stage is what Van De Vanter calls a general purpose analysis engine driven by more powerful language-oriented technologies. This module would allow sophisticated analysis. The goal is to help a developer construct an alternate view of a program based on a different set of rules: renaming variables, classes, and methods; and conducting queries to show where and how data are used.

The underlying goal of Jackpot is to more usefully balance the conflicting demands that every software program makes on the programmer: that code be intelligible to machines as well as to the humans who develop and maintain it. "Good programmers know where the semicolons go," says Van De Vanter. "What they need is more visual bandwidth to show useful information about the code."

Find out more»

Back to top