BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Closures and Preserving the Feel of Java

Closures and Preserving the Feel of Java

This item in japanese

Bookmarks

During the last few years, there has been wide-ranging discussion about adding closures to the Java language, either as part of Java SE 7, or in some future, unspecified release. There have been proposals (BGGA, CICE, FCM) and talk of a consensus.  One way to look at the available proposals is to consider the impact on Java as a language: whether it's possible to undergo fundamental change while still preserving the "Feel of Java". At Javapolis, Joshua Bloch presented his opinion about the controversy, and why he feels that CICE is a more suitable approach.

Describing the feel of Java, Joshua Bloch quoted a Gosling article in June 1997 IEEE Computer:

Java is a blue-collar language. It's not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because we preferred tried-and-tested-things.

He asked, "how are we doing", and answered "not so well." Citing a 427-page FAQ and quoting some users, he held up Java Generics as a change that failed to preserve the feel of java due to the expoential set of interactions between features, and concludes that if the feel of Java is to preserved:

  • We simply cannot afford another wildcards
  • Further language additions must be undertaken with extreme caution
  • Minimal addition to conceptual surface area
  • High power-to-weight ratio

After briefly reviewing the reasons for adding Closures to the Java language, Joshua Bloch led into a discussion of some of the controversial features of the BGGA closure proposal: function types (hard to read, encourage 'exotic' programming style, unexpected interactions); non-local returns, breaks and continues (confusing, insidious bugs, changes meaning); unrestricted access to nonfinal local variables (confusing, performance impact) and library-defined control constructs as a design goal (less rich that purpose-built constructs, potentially slower, adds complexity).

He also reviewed the prime points of the proposal to which he contributed, Concise Instance Creation Expressions (CICE):

  • Concise syntax for anonymous class instance creation
  • Purpose-built construct for automatic resource management

He suggested an alternate solution for those who desire to see a more pervasive approach to language change on the Java platform:

We should keep in mind that there's already a fine programming language for the JVM that offers both of these things, and Java interoperability to boot: Scala

And finally, described two ways forward:

  • Gain more experience with prototypes
    • When we come to an informed consensus, start a narrowly focused JSR
    • This might take a couple of years
    • Precedent established by generics
  • Start a broadly focused JSR in the near future

    • Must permit any point on the Closure Spectrum
    • First task is to answer the two Big Questions
  • We have a big decision to make!
  • It will have a huge effect on the future of the Java platform
  • We must take our time and do what is right
  • We must not risk further damage to "the feel of Java"
  • The reaction from a Javapolis poll was mixed: 30 attendees voted for CICE, BGGA/FCM+JCA received 24 votes and 19 voted for no change. On a heavily trafficked Javalobby thread, reactions were swift and polarized, some felt Joshua Bloch was too biased to present the comparison well. Others seconded the idea that if you desire these features, you should use Scala. Some saw BGGA as a feature that would over-complicate Java, others felt the complexities are rare and shouldn't distract from the everyday case. Carsten Saager likes CICE.  Stephen Colbourne still likes his FCM proposal.

    Neal Gafter's response was short and to the point; he argued that the BGGA syntax will produce simpler code in most real-world scenarios, using Doug Lea's fork-join framework as an example and directs people to read his solution to the concens posed by non-local transfers. Bharath's blog entry goes into detail on an increasingly comon view in the comment threads: that this kind of controversy indicates that we should proceed with caution, and not attempt radical surgery on Java without understanding its consequences. Tim Bray and Michael Kolling have moved into the 'contra' camp: against adding closures to Java. As Tim Bray puts it:

    My argument is simple: Java worked so well because it hit the 80/20 point; for my money one of the loudest, cleanest 80/20 technology victories ever. Subsequent attempts to fill in the 20% were, well, mostly harmless. Until generics, which are a disaster; they have made Java harder to learn and to understand, and you can't avoid them.

    One thing's for sure: we haven't got closure on Closures for Java.

    Rate this Article

    Adoption
    Style

    BT