Platinum Sponsors

SUN

ELCA

Gold Sponsors

AdNovum

Credit-Suisse

Silver Sponsors

SAP

SyBOR AG

Partners

Netcetera AG

JUGS - Java User Group Switzerland

Stadt Z├╝rich Wirtschaftsf├Ârderung

cR Kommunikation

Eveni AG

LiSoG - Linux Solutions Group e.V.

Star Alliance

ICTnet

simsa

Creatronic Media Supply

Media Partners

Netzwoche

inside-it.ch

javamagazine

InfoWeek

IT Reseller

JavaSPECTRUM

APRESS

Day 4: What happened on Thursday, 2007-06-28

Neal Gafter, Google Mountain View, delivered the first keynote address Thursday morning entitled, "Closures for Java ... and other thoughts on language evolution". Dr Gafter explained that extending a language like Java is a heavyweight prospect. Therefore, 1) one should have definite goals in mind before attempting a change but 2) it would be even better if it were possible to solve problems with existing language features. These two observations provide the primary motivation of adding closures to Java. If closures existed in the language, one could simplify programs, reduce a class of bugs resulting from duplicated boilerplate code, and more easily adapt to changing requirements.

Closures are essentially anonymous function expressions that can potentially include encapsulated state. Dr Gafter first showed examples that would benefit from closures by replacing boilerplate code with simple method calls using his proposed closure implementation. His examples included stream processing, timing code, and callback interface programming. Furthermore, this code reduction results in fewer bugs, since the method definition using the closure would now be a single definition of this boilerplate code - reducing a common problem where code refactorings to some boilerplate code might not cover all instances of that boilerplate code.

Closures offer even more promise in (even near-) future problems such as concurrent programming. It will soon become clear that there are better/easier ways to implement concurrency than using the Thread/Lock model.

In particular, if closures were available, the Fork-Join model proposed by Doug Lea could be implemented first as a library routine and once stable, merged into the Java library without requiring a language definition change. He pointed out that while the new foreach loop in Java 5 is a great simplifier, it still results in some boilerplate code for iterating over Maps because you want the key and value on each iteration. With closures one could have implemented Java 5 foreach as well as covering a Map foreach - all without having to change the language. Such a direction would make Java the language be more democratic since anyone could propose changes for evolving the language, instead of depending ultimately on "smoke filled rooms at Sun".

Danny Coward, Java SE platform lead, Sun Microsystems delivered the second keynote address entitled, "Evolving the Java SE and Java EE platforms". First, he described what he thought were the top features in the most recent versions, Java SE 6 and Java EE 5 (also available on his blog), then remarked that the take up of Java 6 since December (2.7 million downloads) seemed to be roughly twice that of the take up of Java SE 5. He explained that Java in future is expected to continue to evolve through the Java Community Process. He announced that general principles used to decide future features in Java SE and Java EE will be based on making things simpler, more extensible, and more performing if possible. Future planned releases include Glassfish v2 in the second half of 2007, JavaFX in early 2008 and JDK 7 in late 2008/ early 2009.