News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Finding PathFinder




June 1, 2005 — 
Every so often I come across a piece of software that stuns me with its potential. Today’s example is Java PathFinder (javapathfinder.sourceforge.net), created by the Robust Software Engineering group at NASA Ames Research Center. I’d not heard of PathFinder until I read a recent press release saying that NASA had put it up on SourceForge, so I logged on to SourceForge just to find out what PathFinder was.

I’m impressed—and not just by the software itself, but by how making it open-source is exactly what’s needed for a valuable resource to reach its full potential. Open-sourcing PathFinder is a brilliant move on the part of NASA.

Without NASA’s original research, PathFinder simply wouldn’t exist. They’ve taken an interesting academic idea that’s been kicking around for a while—finding bugs in software by executing every possible (or at least reasonable) path through the code—and actually produced a program that finds a very-difficult-to-find bug that plagues every multithreaded program: deadlock (where two threads wait forever for each other to give up locks).

Anybody who has spent weeks trying to find a race condition that created a deadlock will immediately understand the importance of this accomplishment. The approach used to track down deadlock can also find other classes of bugs. Right now, PathFinder will find uncaught exceptions, for example, and the technology can be expanded to find other problems in your code.

PathFinder is not a testing framework like JUnit. It actually exercises the code for you, looking for bugs by running that code in a special-purpose VM. (That JVM, by the way, is written in Java. It’s an interesting notion—writing a JVM in Java.)

PathFinder is a research project, however, with no commercial applicability in its current state. The documentation, for example, reads like a dissertation—it’s way too dense to be useful as it stands. You have to be a developer to install the thing and get it running. The two other main shortcomings are a limited source-code size (of about 10K lines of code), which is really mandated by the technology, and an inability to process code that makes native-method calls (AWT, I/O code, etc.). The latter problem is easily solved—in fact, interfaces are provided to do a lot of the work—but these interfaces need to be implemented for all the standard libraries.

Though the sort of work represented by PathFinder is way beyond what the open-source community is typically able to do on its own, productization of research is typically way beyond what the academic community can accomplish. PathFinder would have disappeared without a trace if it had stayed closeted in the bowels of NASA.

Working in concert, though, the government/academic sector and open-source communities can do things that neither could do separately. The software is easily in a state where someone can run with it and turn it into a killer product. The basic research work is done, and NASA has effectively handed the productization of that work over to the open-source community.

The NASA folks benefit from seeing their baby grow up by handing product development over to people who actually know how to develop products, and these people can benefit by creating a killer product from basic research they don’t have the resources to perform.

On the down side, the open-source community seems to have a knack for not developing promising software to its full potential. Often, nobody can be bothered to improve documentation to the point where it can be understood by someone who hasn’t personally worked on the source code. Open-source projects frequently have miserable user interfaces and hideously overcomplicated configuration mechanisms. That is, it’s just as likely that the official PathFinder project will grind itself into dust. The technology is there for the taking, however, either as a pure open-source product or as a larger program that incorporates NASA technology.

(The license agreement seems very generous. The actual work performed by NASA—and any modifications that you make to that work—have to remain open-source, but this requirement does not extend to a “Larger Work” that includes NASA’s engine. I’ll leave it up to the lawyers to decide what parts of the program constitute the “Larger Work” and what parts are natural modifications of PathFinder, but it seems to me possible to build a proprietary commercial product around PathFinder, exposing the source code for only that part of the system that derives from NASA’s original code.)

So, I’m anxious to see how this all plays out. Here we have a project with great potential that solves a real problem, but it’s a project that needs work to realize that potential. I look forward to seeing what the open-source community can do with it.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28634
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading