Skip to main content

Get the Balance Right

Posted by editor on April 30, 2007 at 6:30 AM PDT

An accord on closures?

The "closures debate" in the Java community -- recently summarized in a DeveloperWorks article by Brian Goetz -- is really a tangle of several debates. We might well be discussing three very different things:

  1. Whether to add closures to the Java language
  2. What specifically a closures proposal should address
  3. The specific syntax of a closures proposal

Today's news is that at least one of these has been fundamentally addressed.
Artima reports that consensus has been reached among the competing JDK 7 closures proposals. They cite a blog entry from Neal Gafter, A Consensus Closures JSR Proposal, which he says "comes as close to achieving consensus as I believe possible. All but one of the authors of the three widely-discussed closures proposals have agreed to support it." The proposal defines the problem to be solved but does not mandate a specific solution, though it does offer Closures for Java as an example solution.

So, according to Gafter, an agreement has been reached on what the problem is and what a closures JSR will try to address. That's number 2 on the list above. The next question for the group to consider will be the specific form of their proposal, which is debate #3. Assuming that is resolved and then brought to the community in the form of a draft JSR, it will be up to the JCP Executive Committee (and, really, to the community as a whole) to answer the first question: do we really even want this at all?

2-3-1 might seem a strange way to go about it, but it's possible the closure proponents are addressing the problems in order of difficulty. Rather than get consensus from everyone on the need for closures, they'll get the closure proponents to at least agree on a common agenda, see if they can develop a concrete proposal amongst themselves, and then see if, armed with specifics, they can sway some/most/all of the closure skeptics.

Also in Java Today,

the Direct Web Remoting project has released the long-awaited version 2.0. DWR 2.0's marquee feature is "Reverse Ajax" (explained in a feature article), and also features a JavaScript Proxy API to dynamically generate JavaScript from a Java API. Security improvements help guard against cross-site request forgery and cross-site scripting attacks. Other new features include a much expanded WAR file, support for Spring namespaces and Guice, Jetty continuations, servlet session timeout support, new annotations, and more.

Is EE the right hammer for every nail? Dan Creswell's blog Victims of J2EE Success criticizes some EE developers for assuming an incorrect set of beliefs, namely that "there is nothing beyond the database, POJOs focused purely on business logic, this is distributed programming, Ops is someone elses problem, [and you just] deploy more or bigger boxes to scale." He goes on to say "once you're beyond a certain level of challenge the J2EE way of thought and patterns of design don't work," and lists a series of language/framework-agnostic traits that developers need to handle new and challenging enterprise work.