Closures and Preserving the Feel of Java

by Geoffrey Wiseman on Dec 19, 2007 |

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.

    Related Editorial

    Hello stranger!

    You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

    Get the most out of the InfoQ experience.

    Tell us what you think

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Email me replies to any of my messages in this thread
    Community comments

    Time to have some wisdom by Jean-Baptiste Lalanne

    I think it's time for the community to involve in this process and stop it before it's too late. I fully agree with Michael Kolling's analysis and view of the java users pyramid. I hit it every days i work.

    Java is not the place to make this kind of experimentation. Java 5 has brought enough new stuff and it's too early now to get a real feedback of their impacts. We must wait some years before knowing what will be the cost of generics and annotations.

    The geeks can go to the hybrid langage that got closures like Groovy or anything else if they really need it. Java is a place where only stable stuff should be added.

    Java has gone the way of C++ by Kurt Christensen

    I couldn't agree more strongly with the last quote of the article: "Java worked so well because it hit the 80/20 point". I remember a great presentation by Bjarne Stroustrup back around 1997 at the Computer Literacy bookstore. Someone said that Java looked like a much better, cleaner C++, to which Stroustrup replied that we should ask him about it again in 10 years after everyone was finished adding the features they want. Well, it's 10 years later, and new Java code is starting to look an awful lot like C++.

    Generics should have been the wake-up call for the Java community. Do you really mean to tell me that Java code laden with all the type info is more readable than code that simply casts something coming out of a collection? And how often did you run into bugs involving ClassCastExceptions of the objects coming out of those collections? For me that'd be never, and I'm *hardly* the world's greatest programmer.

    Java was always a bit of a pig, but she was our pig, and she got the job done. Now the youngsters want to put a whole lot of lipstick on our pig, and it sure ain't making her any prettier.

    Re: Time to have some wisdom by Paul Beckford

    As a Ruby fan, I guess it's strange that I find myself agreeing with the above. Java is what it is. It is clearly aimed at a target audience, and as a clear design ethos. Blurring the language and trying to make it into what its not isn't the answer. Annotations and Generics where an attempt to play catchup with C# and both failed IMO.

    If you want language features that aren't provided by Java then select a language that proved tem. There are plenty of languages to choose from.

    Incidentally, on the platform front the JVM seems to be falling behind. There are a number of interesting languages out there like Boo and F# that choose to target the CLR. It may be time to brake backwards compatibility with the JVM, and create a new VM that is a natural host for a broad set of languages. Leave Java the language alone, and attract new interesting languages to the new JVM platform.

    Now that would be a brave move :^)

    Paul.

    Re: Time to have some wisdom by William H

    I agree that the BBGA closures proposal adds a great deal of complexity to the language and I'm yet to be convinced to its benefits. I have to take issue with you on a couple of your points though.
    1) The generics proposal goes back to 1999 at least. (See jcp.org/en/jsr/detail?id=14) – a little before C# existed. Annotations may have been a reaction to C# but I wouldn't know.
    2) I don't think you can describe annotations as a failure. They're very heavily used, and generally well liked in the Java EE 5 and other frameworks – Spring, Seam etc. and will probably see more use in 6.
    3) The JVM is still a more-than-adequate host for a wide range of languages. This is why there are so many languages available for it. See www.robert-tolksdorf.de/vmlanguages.html for a fairly comprehensive list. I don't think the world needs a new JVM. What I think the world does need is a decent language for doing system programming in – i.e. something that actually replaces C++. Neither Java or C# can do this because the VM boundary kills you every time.

    Re: Time to have some wisdom by Dmitriy Setrakyan

    Annotations and Generics where an attempt to play catchup with C# and both failed IMO.

    I would partially agree with your statement on Generics. The problem with Generics, in my view, is that they are too strict. Adding "<? extends MyType>" everywhere is painful and reduces readability. I would rather have "extends" keyword implied, especially for interfaces.

    Annotations, on the other hand, are a huge success. Just to think how much better the code is right now with annotation-based transaction demarcation or remoting in many frameworks. We at GridGain, for example, use @Gridify annotation to annotate the methods that should be grid-enabled and executed on the grid. From usability stand point it's a huge advantage as user code is not bothered with middleware artifacts.

    As far as closures, I think it would be a nice addition, but we need to very carefully think it through to avoid the same missteps as with Generics.

    Best,
    Dmitriy Setrakyan
    GridGain - Grid Computing Made Simple

    Java Jumped the Shark with Generics? by Geoffrey Wiseman

    I've gotta say, Generics seems to be a bit of a 'jumped the shark' moment for a lot of people. It's something that I think a fair number of people were looking forward to, and many still believe adds some value, but we've had to pay a much higher price for it than we had anticipated.

    I'm starting to come around to the idea that what the Java platform needs is a new language in which to innovate while the Java language proceeds gracefully into old age, and Josh Bloch was wont to say, in the Future of Java panel discussion at QCon SF.

    I just wish I felt we were farther down that path. Scala, Groovy and JRuby are all interesting, but I don't feel like any of these is ready to step up and shoulder the burden of the 'future of the platform' yet.

    Re: Time to have some wisdom by Paul Beckford

    The JVM is still a more-than-adequate host for a wide range of languages. This is why there are so many languages available for it. See www.robert-tolksdorf.de/vmlanguages.html for a fairly comprehensive list. I don't think the world needs a new JVM. What I think the world does need is a decent language for doing system programming in – i.e. something that actually replaces C++. Neither Java or C# can do this because the VM boundary kills you every time.


    Not sure everyone would agree that the JVM is a great host for languages other then Java. Like I say, the CLR seems to be doing better here. It could be down to technical reasons, or it could be down to Microsoft marketing the CLR as a multi-language platform, I'm not sure.

    As for annotations, as someone who as stuck with Java 1.4 and xdoclet, I'm happy to take your word for it. Everyone seems to agree that Generics were a bad move though.

    As an old time C programmer, I don't understand your complaint with C++. For system programming C is great, and if you want efficient objects without a VM then C++ does the job IMO. Personally, I think that Objective-C is better, but I don't see the language gap you describe. Please explain.

    Re: Time to have some wisdom by William H

    Well one substantial one is that nearly all of the security exploits that plague us today come down to a single design flaw in C/C++ - that it allows buffer overruns. As computers and their users have got more and more connected this has become more and more of a pain. It doesn't occur in Java or .NET or most other interpreted languages which signal a well defined error condition. You can't, I don't think, write a decent modern OS in C++ largely for this reason which is why we all have to spend our time dealing with firewalls, virus scanners and other preventative measures that should simply be unnecessary. There are other reasons – mostly they come down to that fact that I hate C++ with a passion – but that it the biggest I think.

    I think there are more languages for the JVM then there are for the CLR BTW – there isn't technically a great deal between them though Microsoft decided to play the mixed language card early on in .NET's history as a market differentiation from Java.

    Re: Time to have some wisdom by Michael Neale

    JRuby and Scala are both very advanced and capable on the VM (and used) - improving on a daily basis. JRuby is quickly becoming the leading implementation of the ruby language in a lot of areas. IronRuby is nowhere to be seen. (Could consider Scala to be similar, in some ways, to F#, but not quite).

    But I agree, attract more things for the platform is the way to go.

    Re: Time to have some wisdom by Michael Neale

    I am pretty sure it is down to historical reasons, not technical. That is changing as we speak.

    Re: Time to have some wisdom by Jean-Baptiste Lalanne

    2) I don't think you can describe annotations as a failure. They're very heavily used, and generally well liked in the Java EE 5 and other frameworks – Spring, Seam etc. and will probably see more use in 6.

    Yes annotations are not a failure but i'm wondering how clear will be the java code if every method or attribute declaration starts with 5 annotations or if you use annotation on method parameters (yes it's allowed) with the generics syntax.

    As was saying Joshua Bloch the complexity don't necessary come from a single feature but mainly of the mix of several features.

    Re: Time to have some wisdom by Stefan Tilkov

    I believe C++ offers benefits over C in terms of being able to avoid buffer overruns - the ability to use a decent string class, for example, comes to mind.

    Given that every OS I know is written in C, I believe it can be argued that they could have been written in C++ just as well or better. Which might mean that, according to your definition, there are no "decent" operating systems. Which may be right :-)

    More support for JRuby/ Groovy/ Scala by Thom Nichols

    I don't know why everyone is whining about generics, they work fine. So it is only a compile-time feature. It still provides strict typing and removes explicit typecasting. Wasn't that the point? If I have to add one or two generic type parameters when I declare a field or parameter, so what? I will live with that in order to avoid manual typecasts. And the wildcards in generics are rarely a problem. Get over it. Don't like annotations? Fine, you can stay on Java 1.4, and do all your configuration in XML files. Have a blast.

    Back to the point -- Closures are not that complex. But fine, leave them out of Java, and pour support into JRuby/Groovy/Scala. Personally I found JRuby and Scala syntax to be a bit confusing, so Groovy offers a great feature -- a rich language with extremely low impedance when working in a Java environment.

    Personally, I follow the 80/20 rule to use Groovy -- 80% of my code is in Groovy, and the 20% (or less) that requires performance tuning can be easily factored out into Java. So I lose the expressive language features in order to gain performance. Works great for me.

    Re: Java Jumped the Shark with Generics? by Steve Tekell

    Well if you are not looking for a full replacement, Groovy is ready not to make you life easier.

    Re: More support for JRuby/ Groovy/ Scala by Steve Tekell

    ...
    Back to the point -- Closures are not that complex. But fine, leave them out of Java, and pour support into JRuby/Groovy/Scala. Personally I found JRuby and Scala syntax to be a bit confusing, so Groovy offers a great feature -- a rich language with extremely low impedance when working in a Java environment.

    Personally, I follow the 80/20 rule to use Groovy -- 80% of my code is in Groovy, and the 20% (or less) that requires performance tuning can be easily factored out into Java. So I lose the expressive language features in order to gain performance. Works great for me.


    I am with you here. Not only is Groovy a quick learn for Java developers, but you can switch back and forth between writing Groovy and Java without getting whiplash. I think Groovy is great for people like myself who are mostly developing the final layer of applications rather than app servers, ORMs, and lower level stuff.

    As far as closures. They seemed a little weird until I started using them. Now the idea that they are exotic is silly. Groovy has closures and the code is more readable not less. And it doesn't make your code turn into some completely foreign looking FP language either. Still it's find with me if Java never adds closures. Put more effort into Groovy, et al.

    BTW somehow Groovy 1.5 solved the erasure problem for working with Generics as well.

    People who shrugged off Groovy a year ago as just a toy, need to give it a second look. And if you have some hangups about using it, just get over it already. If you only use for little Scripts, it's still a worthwhile addition to your toolbox.

    The strength of Java compared to C++ was simplicity! by Frédéric TU

    When Java has come, C++ developper has considered Java dev like sub-developper because they don't managed memory themselves and Java wasn't performant!

    Now Microsoft adopt C# which takes the philosophy of Java.

    Standard developpers shouldn't be bother with complexity in their daily coding task. Generics is a really good tool and Annotation too. Most of the people I know are craving not to maitain Java 1.4 code but want Java 5.0 as soon as possible. BUT I use to work in the framework team and most of us know what we do, but forcing std dev to learn many of theses tools just because they integrate complexity in language is a little bit too much.

    They should be left to integrated framework, where you allow them to import great librairy and let in std Java language, simple tool to make them dev business code...

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Email me replies to any of my messages in this thread

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Email me replies to any of my messages in this thread

    16 comments

    Educational Content

    General Feedback
    Bugs
    Advertising
    Editorial
    		 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
    Privacy policy