There has been a lot of chatter about the closures proposal penned by Neal Gafter. And, in particular, whether or not I support it. I absolutely do. My "Feel of Java" talk of many years ago got rather infamously twisted at JavaPolis a couple of months ago. Java feels alive, not stuck in some chisel marks on stone tablets. Closures were left out of Java initially more because of time pressures than anything else. Closures, as a concept, are tried and true - well past the days of being PhD topics. The arguments are in the details, not the broad concepts. In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues. But as is normal in so many design issues, the simplifications didn't really solve any problems, they just moved them. We should have gone all the way back then. Some have criticized the current proposal as being too complex. If you read through all of what Neal has written, you'll see that there are two sources of this perception: the spec is really detailed and explores all kinds of corner cases that never get touched on in most programming manuals; and the proposal is a collection of features that at first blush seem separate, but in fact are deeply inter-related and push each other into existence.


Posted by Kevin on January 31, 2008 at 01:18 AM PST #


Posted by Nico on January 31, 2008 at 01:29 AM PST #

I agree with the sentiment that if we go with closures, then go "all the way", or not at all. The worst possible outcome is to make the same mistake as generics...which did not go "all the way", and stuck us with erasure. This is not an edge case...I encounter erasure frustrations constantly. I guess after being burned so badly with generics, I am extremely skeptical of closures.

Posted by Eric Burke on January 31, 2008 at 02:32 AM PST #


I am very sorry to hear that you feel that I twisted your "Feel of Java Talk." As I hope you know, that was certainly not my intent. (I did, after all, clear the presentation with you before I gave it.)

I thought your "Feel of Java" talk was wonderful when you presented it back in 1996, and I believe it's every bit as valid today. I'm somewhat surprised that you still favor BGGA closures in light of the content of my JavaPolis the presentation. I am still deeply afraid that the adoption of this proposal will harm Java's stature as a "workingman's language." I do feel that we've used up our "complexity budget" on generics, and in particular, on wildcards. But time will tell. It's great that we're getting prototypes for the various closures proposals, so that real programmers can gain experience with them.

Your friend,


Posted by Joshua Bloch on January 31, 2008 at 02:38 AM PST #

Great.... glad to see this is getting more and more support.

Closures is one of the things that really bothers me about Java and fits firmly in the 'hate' category in my love/hate relationship.

I'm holding my breath! :)

Posted by Kevin A. Burton on January 31, 2008 at 02:43 AM PST #

can't there be some sort of meet in the middle approach? Does anyone know how one proposal will win over another? Will there be some sort of JCP vote?

Posted by sboulay on January 31, 2008 at 02:48 AM PST #

+1 on "we should have gone all the way back then"; I was a frustrated Scheme refugee in those days. But, we were aiming at what we thought possible. The smallest JVM change at that point would have hurt our compatibility story, now one of Java's great strengths. Our poor man's closure had to use nominal types, which were all the JVM could give us. (We also were afraid of using up our complexity budget then, IIRC. And after inner classes we got plenty of hate mail of the form "I can't understand Java, you have ruined Java". But they could and we hadn't.) I think we did what we could (rather well) with an immutable JVM.

Thinking further, if we had been willing to evolve the JVM faster earlier, we would have had to learn how to integrate structural function types into the Java of the time. This doesn't seem like a big deal now; maybe we should have tried. Maybe we could have done generics after function types... but maybe the function types would have been a misfit to generic, like arrays. I can't say I'm sorry we have taken the time we have to get it right.

And I'm generally happy with Neal's proposals. (Missing varargs is a gap.) The classic closures and new-fangled Ruby/Groovy-type DSLs mix well into Java, and your comments about deep complexity vs. experienced complexity ring true to me. Ruby is more complicated than Java, yet many workingmen are using it. So, Josh, I trust you'll still speak to me when I say I think the language will bear first-class, full-orbed closures.

Finally, we are no longer in the days of the immutable JVM, and the Java ecology is getting very exciting with the JVM gaining competency on many new languages, especially dynamic ones. Those whose complexity allergies Java 7 sends into anaphylactic shock will find solace on the JVM in Ruby, Smalltalk, Javascript, or some other JVM language (Newspeak, anyone?). The point is Java is not the only language on the JVM anymore. See , and check out the talk slides I gave at Microsoft this week. IMO, the JVM is going to be the best dynamic language platform on the planet.

(Also, +1 on Michael Pollan in your sidebar.)

Posted by John Rose on January 31, 2008 at 05:15 AM PST #

I wonder why so many smart people have such a hard time understanding how average people perceive things. Smart people should be able to understand IQ bell curves and their place on it. I wonder if this lack of empathy is why smart people engineers major languages to climb faster on the complexity curve than the average developer can handle, and therefore slowly falls out of grace in the process.

Posted by Mikael Grev on January 31, 2008 at 06:41 AM PST #

I see it as a very healthy sign that there's been so much discussion about closures, and that the Java community as a whole has the chance to participate in a variety of ways, and is doing so. It certainly indicates that the language is very much alive.

The devil is always in the details with these things, so I personally welcome the fact that there are some very different approaches on the table, which we can compare in order to gain a deeper understanding of the issues involved. In fact it's with this in mind that I decided to try to implement the CICE and ARM proposals and explore them as fully as possible (see

It may surprise some to learn that of the various people who have given me feedback on it, Neal Gafter has been one of the most helpful in suggesting ways in which the quality (and therefore usability) of the CICE/ARM prototype could be improved for those wishing to experiment with it.

John Rose's comments about other languages on the VM strikes a chord with me too. It has become an attractive proposition to implement various languages on the JVM for a number of reasons - a major one is the ability to use Java's APIs, which are ultimately influenced by the features of the Java language itself. Yet, if the Java language doesn't continue to evolve, its APIs may well fall rapidly out of step with those of Java's contemporaries.

Posted by Mark Mahieu on January 31, 2008 at 09:29 AM PST #

RIP Scala and Groovy...
I think the Java language with closures (as well as better package support) will be good enough to be used as the stable layer of most applications. Add a nice JVM scripting on the top of that and it totally rocks. Languages that weren't the best at scripting while trying to simply overcome the major flaws of the Java language might then see their niche reduced IMHO. Java without closures was doomed IMHO, smart move again.

Hope Sun manage to propose both consistent and efficient standard libraries on the top of that. Not easy given that those libs were done before this potential major feature.

Posted by Raphaël Valyi on January 31, 2008 at 09:35 AM PST #

I don't think its RIP any language. Let a thousand languages bloom on the JVM. A better java is nice too, why not.

"Closures were left out of Java initially more because of time pressures than anything else."

- wow, its good finally to hear the real reason (people twist in all sorts of other meaning, but in reality, Java was a project and on a deadline like anything else).

Posted by Michael Neale on January 31, 2008 at 12:10 PM PST #

Specifications difficult to understand are likely to produce code difficult to read and write.
I welcome closures, but the proposal is still complex.

Posted by Daesung Park on January 31, 2008 at 03:01 PM PST #

I think adding closures to Java is a good idea. But it has to be as simple as possible. I know many Java programmers who started with Ruby or Groovy and closures where always one of the things they had most trouble with when starting to use them.

Posted by Markus Jais on January 31, 2008 at 03:23 PM PST #

This is disheartening, to say the least. I'm quite disappointed to see Josh's fervent appeals to protect the sanity of the Java language getting lost in the noise. I'd also urge everyone to read Tim Bray's post ( on this issue. Instead of having closures shoved down the throat of Java developers, I'd rather see the Java community focus efforts on the mlvm and leverage closures in other languages running on the vm.

Posted by BharathR on January 31, 2008 at 06:28 PM PST #

I'm glad to see your support for closures, but it would have been preferable to see some discussion of other proposals.

The FCM proposal - - that I have produced with Stefan Schulz favours a style much closer to Java than BGGA. And we are even considering whether to remove 'method types' (function types) from the next revision. I, like Josh, find them to be a very complex addition to Java, and not well fitted to it's style.

Finally, I would say that 'going all the way' is not necessarily the right solution for Java. As developers, we have a natural tendency to over-analyse and over-engineer. We really need to ask ourselves why Java needs function types, and why it needs non-local returns. My opinion is that these features would probably be no-brainers for a \*new\* language, but they will be horribly disruptive for the Java language, style and ethos of \*today\*.

Posted by Stephen Colebourne on January 31, 2008 at 09:03 PM PST #

I am one of those who dropped Java and went forward to C/C++. Yes, I mean \*forward\*. I have had it with Java. A decade of waiting that things are finished. A decade of half-arsed APIs, never finished, never bug-fixed, never cleaned up.

And what do you Java fruitcakes do instead of finishing all the unfinished junk you have in Java? You throw in more junk. You rammed generics up our arses, without lube. Now you try the same with closures. Sorry, I have real work to do and my arse is no longer available for your entertainment.

Posted by Marek on January 31, 2008 at 10:35 PM PST #

Great! I didn't understand the people that seem to be intent on setting Java in stone and leaving it as some kind of lame duck. All the while going on about their new favorite language which has full support of closures.

I also like the type inferencing compared to .NET's model where you always have to define a type for your delegate.

Posted by Chris on January 31, 2008 at 10:56 PM PST #

I highly anticipate the inclusion of closures in the Java language. Not only will it lengthen Java's life span, but make it more attractive to the next generation of high level programmers. ( That is, If they learn the merits of closures from their mentors )

Posted by Derrick J. Wippler on January 31, 2008 at 11:19 PM PST #

Such a shame. Closures will ruin Java.

Posted by Ben Loud on February 01, 2008 at 12:00 AM PST #

FCM does look more like Java and is more likely to be palatable to existing Java developers.

Posted by Tom on February 01, 2008 at 12:14 AM PST #

You inspired my latest comic:

Posted by Eric Burke on February 01, 2008 at 12:39 AM PST #

James you said in this blog:

"Closures were left out of Java initially more because of time pressures than anything else."

but in 1996 you said:

"Java has no functions. Object-oriented programming supersedes functional and procedural styles. Mixing the two styles just leads to confusion and dilutes the purity of an object-oriented language. Anything you can do with a function you can do just as well by defining a class and creating methods for that class."

I'm late to this debate so I apologize. I just want to know (this is not a rhetorical question) do you now disagree with this statement? As far as I can see a closure is a function.

A function asks "what do you want to do?", but OO programming forces you to ask "why are you doing it?". In other words if you are doing something, then most likely you will want to do it again - so OO says: define it properly the first time. Associate it with the data it supposed to work on (a method in a class) or declare clearly what it's intention is (an interface).

Everyone looks at inner/anonymous classes as hacks trying to be closures. I see it the other way. A closure is hack. It's a sloppy shortcut when we, as programmers, want to do something quick but don't want to take the time to properly define what it is we are doing - which is what OO is about. Closures are needed in scripting languages, for sure, but Java is an application engineering language - I don't see that they are needed.

Posted by Michael Brereton on February 01, 2008 at 01:41 AM PST #


Oh boy, I'm really glad no one has any ammo to throw back at me for things I said over a decade ago.

It's possible that even old timers(just kidding =p) like James may sometimes change their minds about beliefs over time. I'd say it's even natural and necessary for beliefs to change over time for most intelligent beings.

Posted by Jesse Kuhnert on February 01, 2008 at 03:22 AM PST #


1. Because something was said over a decade ago does not mean it is no longer valid. "Most intelligent" beings recognize that.

2. I asked a question "Do you now disagree with this statement?". I even pointed out: "this is not rhetorical". I was not calling him a liar or calling him inconsistent or using "ammo". I asked a question.

Obviously I am aware that even old timers change their mind. Obviously I am aware that this could be the case here. Obviously I am aware that beliefs have to change. But some intelligent beings ask questions, we don't make assumptions. I have not had a reply from James and if James has not told you the answer, please don't presume to answer for him here, especially adding attitude into the mix.

I'll explain it so all intelligent beings understand it.

1. His statement in 1996 was clear and had come after long analysis of multiple programming languages over multiple of decades.

2. That statement, and therefore the principles which it was based on, is in conflict with the statement made that the reason closures were left out was mostly because of time constraints.

3. Why did he say at that time functions were left out because of a principle (its a bad idea) and say now that functions were left out because they didn't have time to put that in.

4. Either the 1996 statement was incorrect or the 2008 statement is incorrect. Which is it?

Obviously I am a long time Java programmer (I read that 1996 paper when it came out (in 1996) and gave it a standing ovation - didn't you hear it?) and have the deepest respect for James and his works. So I do not believe he is a liar. But if you changed your mind why not simply say - I've changed my mind. Why rewrite history - intentionally or accidentaly?

Again - not a rhetorical questions, so if you don't know the answer don't pretend to answer it.

Posted by Michael Brereton on February 01, 2008 at 04:54 AM PST #

I agree with Joshua Bloch. The main reason I (and others I talk to) use Java is because of its simplicity. I've followed the Closures debate for a while now and I feel very strongly that Closures' power does not justify its complexity. Joshua Bloch is right to point to the Generics Wildcards feature that should have never been included. We should learn from that mistake.

Posted by Gili on February 01, 2008 at 05:12 AM PST #

"a collection of features that at first blush seem separate, but in fact are deeply inter-related and push each other into existence"

The word you are searching for: complexity.

Posted by erickson on February 01, 2008 at 06:57 AM PST #

@Michael Brereton:
Thanks a lot for you post!!! I completely agree with you (and James-ten-years-ago) regarding OO and Java. I also do not understand how colsures fit into OO Java. I tried to ask about it authors of those closures proposals but nobody ever replied. They all are so exited "hacking" JVM/compilers and do think about design/methodology problems.

Posted by Yury Mishchenko on February 01, 2008 at 08:35 AM PST #

@Michael Brenton
Your post says it very well. Nothing to add.

@ James Gosling.
Back when I learned Pascal we were strongly told that we should include all variables modified in a function in the argument list, to avoid surprising side effects, because they are a horror to debug. Now you praise closures. Function pointers in a OO language (what a bad idea) that gain their "power" from explicitly using side effects! They might be a good thing for OO scripting languages to keep things short but they are a nightmare for a language specialized in producing code that has to be maintained.
I now learned that Mr. Gosling seem not to have understood, why his baby Java grew up so well. The KISS elegance that draw so many developers to the language was no smart move but just the accidental consequence of a deadline. Not a good perspective for Java's future. Now Mr Gosling scarifies it in a stupid arms race with C# and the scripting language of the season. We should instead of adding a complete new level of complexity to Java think how we can fix generics and get rid of the distressed and superfluous wildcards.

Posted by aehrenr on February 01, 2008 at 07:16 PM PST #

Indeed aehrenr, I wish that just 1/10 of the propaganda effort to force-feed closures down Java programmers' throats would be used to fix generics.

What I see is that the proponents of closures are absolutely uneducatable. When the public discussion (Mr. Gosling deprecatingly calls it "chatter") about closures started I was surprised about the brazenness and brutality with which the proponents operated. Steamroller style.

I have not seen a single response from the closure proposal drivers honestly and seriously addressing the concerns of the significant part of the community that doesn't want closures. I see stonewalling and labeling opponents as being stupid and "not getting it". Maybe because the proponents got away with generics they think they can get away with anything. Sun reminds me of THE phone company. "We don't care. We don't have to. We are the Java company."

Right from the beginning the proponents behaved as if the decision to add closures to Java was already a done deal. As if it wasn't a question of "if", but only "how".

And since today I indeed think that it is a done deal. Reading Mr. Gosling statement I think the public debate about closures is just a dog-and-pony show. I wish Sun and the key figures in this disgusting charade would at least be honest.

Posted by Jleader on February 01, 2008 at 09:19 PM PST #

I thought your "Feel of Java" talk was wonderful when you presented it back in 1996, and I believe it's every bit as valid today. I'm somewhat surprised that you still favor BGGA closures in light of the content of my JavaPolis the presentation. I am still deeply afraid that the adoption of this proposal will harm Java's stature as a "workingman's language." I do feel that we've used up our "complexity budget" on generics, and in particular, on wildcards. But time will tell. It's great that we're getting prototypes for the various closures proposals, so that real programmers can gain experience with them.

Posted by ilan on February 01, 2008 at 10:12 PM PST #

I am deeply worried about this push to bring closures into Java, which is at a stage of momentum that it already seems unstoppable.

Many people have remarked in the comments above that simplicity is important, and that it should be as simple as possible. There are several problems here.

One is that simplicity conflicts with retro-fitting and backwards compatibility. That is because we already have large numbers of libraries written without closures, which would presumable have to remain. We then get another set of new libraries with closures (after all, that's what they're for) \*in addition to\* and not instead of the old ones. So what we get is redundancy.

Redundancy introduces complexity.

Competent programmers will still have to know the "old stye", since they need to be able to read existing code. And they need to know the new style. They need to know a lot more with every change, because things do not get removed. This is not a good basis for language design.

The other problem with simplicity is that it is a very subjective measure. We (the people having these discussions) are not your typical programmer. I do not mean to suggest that average programmers are dumber, but there are different forces and priorities. Average programmers do not know the language half as well as the people arguing here about simplicity.

I have argued previously that the closures proposals should be properly user tested (see ). This is common practice in HCI. This also does not mean that end users of computer systems are all dumb, but that complexity can still overwhelm them.

The complexity of Java with closures will be significantly higher due to the fact that it is retrofitted than it would be had we got a clean slate. In addition, the ability in BGGA to essentially create your own control structures directly harms readability. The complexity increase may do more harm in the community at large than the benefits it gives us.

The fact that many people here find closures simple and straight forward means nothing. The fact that you are participating in discussions of future language versions makes you a non-typical programmer.

Let the different proposals shoot it out properly. Let's do some testing to see which of these proposals really has the best pain/benefit ratio, with "Java without closures" being one of the candidates. But let the test involve the masses of people who will have to use this, not just those of us who would list language design as one of their hobbies on their CV.

Posted by Michael Kölling on February 02, 2008 at 12:21 AM PST #

I am deeply skeptical of the value of closures, Gosling's seal of approval or no. Although I detest Eckel's rhetoric in "Java's Evolutionary Dead-End", he's right that Java the language can and should be "old faithful".

Gafter's own comments on his proposal speaks volumes:

"Most programming languages are turing-complete, so the power of closures do not arise from their ability to compute things that cannot otherwise be computed. Rather their expressive power arises from being able to abstract over things that you simply could not abstract over before. In the case of closures, it is the ability to define APIs that abstract over an arbitrary statement or expression. Writing such APIs simply isn't possible in Java today."

His last statement is simply false. It is entirely possible to "abstract over an arbitrary statement or expression". That is, in fact, why interfaces are so powerful. It just so happens that Java allows you to abstract over named \*blocks\* of statements called "methods". In the degenerate case that block can contain one statement, and wallah! a closure. This may be cumbersome, ugly, etc. but it's hardly a limit on abstraction.

I don't know about you guys, but I've never felt like Java was missing closures. E.g. I've never been happily coding along and then got stuck thinking "gosh, if only I had closures!" Sure, I've wished for simpler property syntax, some sort of delegate/mix-in support, and (especially with Swing) some sort of "with" syntactic sugar. I've even hungered mightily for CJAN and "here doc" syntax. But closures? Never.

Gosling can defend Gafter's proposal's complexity all day long as being "just necessary for the edge cases" - but that misses the point. What I don't get is the need for closures, and no-one seems to be able to articulate that very well, and most attempts seem to quickly devolve into a kind of sneering elitism, "oh, well if you don't understand why we need them then you must have a mere bachelors degree from an inexpensive public college. I have a PhD from Harvard (or Rochester), so I don't need to answer your stupid questions."

This argument I find strangely uncompelling.

Posted by Josh Rehman on February 02, 2008 at 02:41 PM PST #

The closure supporters are, IMHO, not real programmers.

You only become a real programmer once you are forced to debug tens of thousands of lines of someone else's code, at 3 AM, on customer premises, with a deadline of 9 AM for a multi-million dollar contract.

Then you pray that the code was written by someone competent who understood the value of simplicity and maintainability. You pray that it wasn't a CS major or a CS PhD, fallen in love with the latest CS buzz. You pray that it wasn't an "Enterprise software" consultant.

You want simple, clean, easy to trace code. You don't want having to work through abstruse abstractions. You don't want 24 indirections and layers. YOU DON'T WANT MAGIC in any form or shape.

What you want is to have a change, a change to survive that suicide mission.

Aren't there enough languages out there for the eggheads to play with? Do they really have to make the jobs of real programmers so much harder?

Please kids, go away and ruin someone else's language. And only come back when you have grown up and became real programmers.

Posted by Frank Torenges on February 02, 2008 at 08:14 PM PST #

Frank: Since when are closures magic?

Posted by Steven Huwig on February 02, 2008 at 10:38 PM PST #

There's a point at which you can no longer change a language in a sensible fashion and retain backwards compatibility. Java long ago passed that point.

Closures are feasible if and only if we remove inner classes from the language and everything else closures render irrelevant and a bad idea. Closures are sensible only if we are willing to redesign everything to make sense in a closure-based environment.

Unless you're willing to make that hard choice, closures will cause far more harm than good. We cannot consider what would have made sense to do in 1995. That ship has sailed.

Posted by Elliotte Rusty Harold on February 02, 2008 at 11:08 PM PST #

Personally I would like to see something like closures in Java.

However, what I really wish is to reference Java fields and methods in a compiletime safe way. This wouldn't be usable just for closures but also to associate metadata to Java elements in a much more flexible (because non-static) way then Java annotations can do.

Posted by Jörg Waßmer on February 02, 2008 at 11:29 PM PST #

I totally agree with all those sceptically about yet another bolt on feature for Java which makes live in some special circumstances easier but the language harder for every one else.

If you need closure, use a language that was designed with closures in mind and stop spoiling Java.

Posted by Peter on February 03, 2008 at 04:07 AM PST #

In an OO language everything should be an object. The problem with closures is that they need to be wrapped in an object to make them work with objects (Neal calls this closure conversion). Like any sort of wrapping there are problems (think of autoboxing of primitives).

A better solution is short syntax for creating an instance of an inner class. If you want write access to local variables then allow that for inner classes.

Lets turn the question round, what can you do with a closure that you can't do with an instance of an inner class?

Posted by Howard Lovatt on February 03, 2008 at 05:14 AM PST #

You know this whole closures debate is making me dread the release of Java 7, no matter what the result is. The debate has created a HUGE split in the community. Whether they end up in the language or not doesnt matter so much anymore, either way, there's going to be huge uproar by those unhappy with the decision, and there's going to be lots of negative press about Java, and I expect it will completely overshadow the release. I can see the Slashdot headlines now. Its such a shame, but thats what happens when people spend so much time talking about the language, when really its the breadth and functionality of the APIs that really matters, and that's where Java really shines.

Posted by Ben Loud on February 03, 2008 at 12:52 PM PST #

Since Mr. Gosling decided to delete my first response to Steven Huwig's

> Frank: Since when are closures magic?

only this: Look at the syntax (from the same people who brought us generics ...). Now imagine you have to untangled a bunch of =>, {}, invoke(), decorated with some generics at three in the morning, written by someone who really wanted to show of. Good luck with that.

To Mr. Gosling, thanks for confirming that you don't want to listen to arguments if they spoil your closure fun. So when was the final decision to add closures to Java made? Back in 2006?

Posted by Frank Torenges on February 03, 2008 at 04:23 PM PST #

[Trackback] Java world is divided over closures. Once section don’t want closures in Java. Another section wants closures, but divided over syntax. Check what James Gosling has to say about it, here. ...

Posted by Rambling on February 03, 2008 at 04:41 PM PST #

@Frank: You can write unmaintainable code in Java 1.0. Generics and closures are there to help write more maintainable code -- like any language construct they can be abused to write impenetrable code instead.

I do agree that Java has some decisions and APIs that will make the situation bad from a syntactic and a legacy API perspective, as Elliotte Rusty Harold points out.

But my point is that closures are not in themselves any better or worse to debug than more conventional "enterprise software" Java code. Either your predecessor had a clue, or they did not.

Posted by Steven Huwig on February 03, 2008 at 10:26 PM PST #

Mr. Gosling,

please reconsider your decision. Whether you intended that in the beginning or not, the best thing in Java (language) is not that it is a progressive language, but a language that can be learned very easily, that can be completely memorized by the average coder and most important, that forces you to write code that can be maintained relatively easily. Even if the code was written by someone else, who was not terribly competent :-)
This is the gap Java filled and, oh yes, it is very portable and has many APIs available. Something like this was and still is needed. Not a fancy language. There are many fancier ones out there.
Java as a language is well past the point of development where it should change fundamental concepts and BGGA would be a very fundamental change. Most developers out there haven't yet swallowed generics. They are, in their complexity, a very unfortunate extension, especially the wildcards. List<Object> should have simply been able to hold List<String>, containers without generics should have been regarded as <Object> types, new T() should have been possible and everything would have been intuitive. Wildcards are a experimental feature that should have never made it in a mainstream language. Don't repeat the mistake to add complexity that is useless in the majority of use cases but instead let us all work hard to reduce complexity of the language again. This is real progress in the Java case: To identify things that should be streamlined. Many constructive proposals have been made in this direction. To reach a compromise on closures please lets use the suggestion of Mr. Bloch to simplify usage of inner classes. Most of the things that average programmer can do with closures can be done this way. There is Groovy for the people that are addicted to the dynamic type of coding. It includes closures! I happily use it as a glue language. There is Scala as a new language bringing fresh concepts. Closures are included in all their glory! I am currently discovering it. And there should be a Java, optimized for the dirty day to day business of the everyday coder (and there is JRuby, if you can stand the syntax :-)). Sun should put its energy in building new APIs and promoting all these languages as first class citizens (eg. Netbeans integration). This would enable a happy living of us all on the Java platform, with all our diverse requirements and wishes and taken together we still have more features than C# but everything is much more readable ;-).

Posted by aehrenr on February 03, 2008 at 10:56 PM PST #

I'd like some other pain points were "fixed".

The idea of structuring the language and api's around inheritance seems really stupid now. Imagine if the language allowed an easy way to compose objects as simple as inheritance. A wraps key word around a interface for example - so that there must be a constructor with a Map argument (ex).

The other things mostly revolve around the limitations of interfaces for api evolution. Face it the jdk is a mess. LayoutManager2? GlyphPainter2? How about the CharSequence that allows charAt(int) but not getChars(char[], int, int)? Or the mindnumbing Enumeration in swing.text? Or the lack of sort in List? or the swing.text Element tree structure that is not iterable?

Posted by paulo on February 04, 2008 at 10:16 AM PST #

The addition of function pointers (call them "closures" if you like to fool those who don't know better) to Java will be the final nail in the coffin of the language and platform, rather than (as the proponents scream so loudly) its saviour from the onslaught of "dynamic" languages.
Most people and companies are already sticking with 1.4 or at most 1.5 because of the terrible decisions the JCP made for 1.6 (and to some degree 1.5 as well). The 1.7 proposals reconfirm that and will cause the vast majority of current Java users to look elsewhere for future projects.
Already we see a strong tendency for new project proposals to look seriously at other technologies because of the negative way Java is developing. This will speed up if closures are added to the language to the point where the majority of projects (even in traditional Java shops) will adopt other technologies instead.
Those other technologies may well include closures (or function pointers) themselves, but will have been designed around them rather than have them retrofitted for marketing purposes, as is the case with pretty much everything that's added to Java lately, and added in a halfhearted effort at that.

Posted by J.T. Wenting on February 04, 2008 at 04:21 PM PST #

What the proponents of function pointers (thank you J.T. Wenting - I will use them by their correct name) don't realize is that, unlike other languages, Java was founded on certain principles. Read the 1996 white paper yourself if you don't know or believe that (a google search for "java 1996 white paper" will take you straight to it). This is what made it unique and this is why many developers (those responsible for maintaining code - not just writing it and moving to the next project) went to it. Those who are making these changes, trying to make it a "dynamic language" (what they really mean is "hip" - like Ruby, Python et al), don't understand that in that arena - the arena of "me too - I'm powerful and easy" trendy languages - Java has ALREADY lost. It lost a long time ago. People would prefer to use Flash to build huge web based apps rather than Java. So rather than stay in an arena of one, where serious developers are assured consistency in the language, and therefore consistency from their programmers, they are choosing to join in the fight to prove that Java is the new bees knees. It's not going to happen. Do you believe they will now accept Java as a "good" language because of this one change? They actually don't know the difference between a scripting language and an application engineering language - their side-by-side comparison of Java to Ruby, JavaScript, Python etc. proves that fact. Do you really believe that adding pointers to functions will win over swarms of programmers?

Mr. Gosling's lie (I'm sorry Mr. Gosling, but after nearly a week of not responding to your own blog [why have comments if you don't respond?] I can only come to the conclusion that your refusal to clarify why your current account of what happened in 1996 100% contradicts what you said in 1996 is due to the fact that you know that one of them is a lie) that it was time constraints that kept pointers to functions out of Java is proof that the future of Java will have nothing to do with software engineering principles and everything to do with fashion.

The sad thing is, by reading the comments here, and elsewhere, it is clear that the ones against these new changes are the ones that have stuck with Java the longest - your most loyal users, the ones who actually took a risk to use your new language in the first place. And believe me! Initially its performance was so awful it was actually embarrassing to give demos of Java applications! For the first few years - I had to use Microsoft's JVM because Sun's was so truly awful. But we recognized its potential, its completeness and its principles as sound, and our patience paid off. Now, apart from a slow startup time, the JIT compiler makes Java application run beautifully - a superb piece of software engineering I must say. But now, our voices count the least - old timers too dumb to understand that change is good. So after you lose a large section of your long time users, and your new users will very quickly move to the next trendy language next year - then who will this language be for?

Posted by Michael Brereton on February 04, 2008 at 10:37 PM PST #

One of my biggest concerns with closures is that I'm certain it's a very large undertaking. I have yet to hear a clear benefit to having closures. That is, closures doesn't allow you to do something that can't be accomplished already. Whether or not one way is better/more readable is subjective. So wouldn't a better usage of time and resources be placed elsewhere? Say, providing features that simply cannot be accomplished with java currently, or fixing certain broken APIs. I'd vote for definitive improvements over something that has the community so divided.

Posted by Mike on February 05, 2008 at 12:39 AM PST #

Closures are no function-pointers! Closures are objects which consists of an environment (the values the closure 'closes-over' - hence the name 'closure') AND a 'function-pointer' (or in OO-terms: A method of the object). So obviously Java already has closures: Every object is one! Now closures are also used for a certain implementation of lambda calculus in combination with static scoping: Here the environment is given by the static scope of the closure. In Java this is accomplished by annonymous inner classes (AIC) but with the small (and in fact very good and clever) limitation to immutable ('final') variables.

So Java already supports closures and even lambda-expressions with static scoping. What the BGGA approach is all about is NOT to add closures to the language. I tries to add:
(1) a more concise syntax for the already existing closures
(2) non-local returns
(3) exception-transparency

Those three points are by no means neccessary to have 'closures' in the language. With AIC closures are already existing in Java and every programmer who has used AICs (for example in Swing-programming) has already used closures - even if he may not have noticed it. So BGGA is not about 'closures or not', its about EXTENDING the ALREADY EXISTING implementation of closures!

I'm totally opposed to BGGA because its much to complex and totally against common use practices in Java. Joshua Bloch pointed all those problems out in his Javapolis presentation ( and I'm totally with him that BGGA is totally against the 'feel' of Java. I also like the ARM proposal because it's a sensible solution to a very real and common problem in Java-programming. Solving this problem in a specialized and easy to understand way instead of creating a "can do everything somehow but nothing really good"-solution like BGGA is very Java-esque (I'm not sure about CICE because it don't really solves any problem).

If BGGA is really added to Java, we have the same (and even worse) situation as with Java-generics: A over-complex solution to a problem which most programmers won't ever understand completely. But while the problem generics solved was really existing (static typesafety for generic containers), and only the solution wasn't really good, with BGGA the solution should solve a problem which doesn't even exists!

Posted by Karsten Wagner on February 05, 2008 at 01:39 AM PST #

Closures are the OO equivalent of function pointers.
In Java terminology they will allow you to pass a reference (Java's closest equivalent to pointers) to a method (Java's name for functions) as arguments to other methods.
That's exactly what a function pointer does.

Some "proposals" may well try to hide reality behind smokescreens of obscure syntax designed to make it look like something else (as well as to make it look like other languages, usually the language du jour) in order to make it seem like a responsible idea, but that changes nothing.

Function pointers (call them closures if it makes you feel better, more politically correct) are fundamentally in opposition to the entire concept of object orientation, the concept that everything is an object.

There's enough of that in Java already left over from the early days, some of it useful (primitives), some of it less so (marker interfaces and the ability to have fields defined in interfaces), but that doesn't mean we should add more of it just for marketing's sake, because it looks good in a sales brochure aimed at people who're easily won over by feature lists and will jump ship whenever something with an even longer feature list comes along in a few months.

Enough's enough. As it is I'm working on creating a decent exit strategy so I won't be the last one to abandon the sinking ship after the grounding I see coming inevitably if the current "strategy" for "improving" the language isn't abandoned for a far more sensible system (maybe something like the current C++ system, which takes a long time to really make sure that what they decide is a good thing and doesn't listen to everyone who just screams loudly enough that something MUST be a good idea because XXXXX has it too).

Posted by J.T. Wenting on February 05, 2008 at 04:14 AM PST #

Sorry, but that's wrong. Let me quote Wikipedia:

"In computer science, a closure is a function that is evaluated in an environment containing one or more bound variables."

If you read this carefull you see that by using OO termes, this simply describes an object with a single method. The method is the 'function' and the 'bound variables' are the fields of the object. Because of this I can only repeat to point out that we ALREADY HAVE closures in Java!

A 'function pointer' is no closure because it has no 'bound variables'! You can use a closure like you can use a function pointer but not vice versa. But you can also use an object as a function pointer: Just create a class with only a single method (in Java termes: An interface with only one method). This is also a function pointer and you supply code to it by implementing the interface.

Posted by Karsten Wagner on February 05, 2008 at 09:32 PM PST #

It's really sad what is happening here, I don't understand why not to leave Java as it is for a while, and let it settle down, I'm in the IT education business, and i've been talking to a few colleagues and alumnus on "CLOSURES" and the response had it's not positive at all.
Seeing this in a student prospective is damn discouraging.

Posted by Mark O'connor on February 06, 2008 at 04:29 AM PST #

If this nonsense makes it into the language many longtime Java advocates and users will indeed leave Java, Mark...
I know that's not what you meant, but it is what will happen.
Or if not leave Java, then draw a line in the sand and stop adopting new versions past 1.5 or 1.6 (which is in fact already happening, with a lot of companies refusing to go beyond 1.4 or 1.5).
I don't care about students so much as about seasoned professionals. Students don't have to learn the latest and (supposedly, though certainly not in this case) greatest. Their main purpose is to learn to learn, if that learning is done using current industry standard tools so much the better as it makes it easier for future employers to integrate them but it's certainly no requirement for their success as students.
Professionals on the other hand need solid tooling that's not due to change on the whim of some marketeer or for political reasons (and "closures in Java" is a combination of both, Sun wants it for marketing reasons, Neal and Josh for political reasons (and to grease their own egos too maybe)).
Professionals are left in the crossfire with 2 options: freeze their skill level at a point below the state of the art, which is bad for your career in the long run, or abandon a decade or so of acquired skills and move away from Java to other platforms.
Many will choose the first in the short term, while preparing their exit strategies in order to have a reasonably smooth transition into new employment, but will probably have to take a financial penalty for that (both in self-paid training and loss of salary due to loss of seniority).
And all that because some guys at Google want to see their names on a massive language change.

Posted by J.T. Wenting on February 06, 2008 at 03:19 PM PST #

Post a Comment:
Comments are closed for this entry.



« July 2016