News
Java Seeks Closure on Closures
- By Joab Jackson
- May 8, 2008
SAN FRANCISCO, CALIF. -- If there is one topic that seems to get Java programmers excited, it's the question of whether to include a new feature called closures in the next version of Java. Advocates say closures would bring more flexibility to the language, but others worry it might encourage bad coding practices and make the language more difficult to work with.
The debate surfaced again this week at the JavaOne conference here, when Neal Gafter, a software engineer at Google, presented his proposed specification for adding closures to Java. The specification, called BGGA, was named after its authors: Gilad Bracha, Gafter, James Gosling and Peter von der Ahé. Gosling is the founder of Java.
Closures are blocks of code with unbound variables, or variables that are not assigned until the closure is called. Although they occur in Haskell and some other functional programming languages that are used relatively rarely, closures are not a feature of Java.
"A closure expression in a program…creates an object. The object wraps up the code that is the body of the closure and anything that is referenced from enclosing scope, such as local variable. It wraps them up and packages them in an implementation of some interface, and that interface is whatever interface type is expected in the context of the program," Gafter said. Closures are sometimes called function objects or anonymous functions.
Closures look different from most Java code. BGGA introduces a new syntactic form for Java, one markedly different from the usual Java format, resembling the often-dense format of functional languages.
Nonetheless, adding BGGA-styled closure functionality to Java 7 would be beneficial in a number of ways, Gafter said. It could potentially reduce the amount boilerplate code a programmer must write. Programmers could write a single closure that could be called from multiple instances by using a short application programming interface. He offered one example of a performance monitoring function, which may be added in selected places in a program. The function collects performance data from in various points in the program and then submits the results to a database. Without closures, the programmer must write much the same code repeatedly. Under closures however, the code could be defined as an application programming interface that could easily be called within the main body of the program.
More important, closures could make better use of multicore processors. Many languages have libraries that can perform actions on aggregated data, such as a list or an array. In Java, however, actions on aggregate bodies, such as sorting or filtering, are usually performed by using a programming loop, which performs the same action sequentially on every member of the set.
"The advantage of using these aggregate operations with closures is that the code can automatically be parallelized. It makes it very easy to take programs written to be sequential and parallelize them just by using a different library," Gafter said.
He offered an example of a simple function that can find the highest grade point average from all the students in a graduating class. A traditional Java program would use a loop to find all the students of a particular year and then compare each student's GPA, keeping the highest GPA. At the end of the process the highest GPA will be obtained. The same function written as a closure would parallelize the process by filtering the students of the year needed and then finding the maximum score. "Closures compute the results all at once," Gafter said.
Despite the fact that heavy hitters such as Gafter and Gosling are backing closures, at least part of the Java community continues to resist the idea. After the main presentation, one attendee asked Gafter if he thought closures introduce unneeded complexity into Java.
"One of the arguments against closures is that it is difficult to write them correctly, and people will abuse them and misuse them," the attendee noted. Another attendee wondered if the closure syntax was difficult to read, which would make debugging the language more difficult.
Earlier this year, Java.net held an informal poll of Java programmers on whether closures should be included in Java 7. More than 61 percent of the respondents voted for some kind of closure, but almost 38 percent indicated they wanted no closures whatsoever in Java.
In addition to BGGA, other closure proposals include First Class Methods and Concise Instance Creation Expressions.