News

Inspection service focuses on Java resource leaks

• By Rich Seeley
• June 11, 2003

Resource leaks plague Java code, says William Payne. Payne is president and CEO of Reasoning Inc., a Mountain View, Calif.-based provider of software inspection services.

Reasoning, which recently began to offer a code inspection service specifically designed for Java, will be at the JavaOne Conference in San Francisco, June 10 through 13, to announce its new facilities for catching resource leaks in Java.

The problem of resource leaks, especially in file handling, showed up as Reasoning began running customers' Java code through its automated analysis system, explained Jeff Klagenberg, product development director.

"As the customers went through our Beta program and we learned a lot more about the Java environment," he explained, "we realized that one of the issues they were dealing with is that Java, although it handles memory as a resource, doesn't necessarily handle other types of resources such as sockets and files, in particular."

One of the most common resource leaks in Java occurs when programmers fail to pay enough attention to the danger of leaving files open, he said.

"Basically what will happen is that a developer will potentially open a file and not close it, assuming garbage collection will save [it]; it does not necessarily do so on a timely basis," Klagenberg said. "Files are a more limited resources typically than memory is. So what will happen is that you can potentially run out of file handles and your application will therefore not be able to open another file."

At that point the Java application with too many open files will hang up, he said.

Reasoning is a 20-year old company that provides automated code analysis for customers including NASA, Toyota and Cannon, said the firm's Payne.

Customers ship code to Reasoning, where it is run through an automated process to analyze it, eliminate false positives and pinpoint defects. Analysis of the code and preparation to reports typically takes 10 working days, but saves untold hours of programming and testing time, Payne said.

"We provide them with a defect-by-defect listing, telling them where the defect is, why it was created and showing them the actual piece of code that created the defect," he explained. Usually a programmer working from the list can fix a code defect within five minutes, Payne added.

Links:

For other Programmers Report articles, please go to www.adtmag.com/article.asp?id=6265