Language Parity: Closures and the JVM

Looks like the slides got corrupted along the way (text is just random letters) and video stops after 30 seconds.

Fixed

Indeed!
I love listening to Neal talk. So relaxed and insightful.

I don't know if he was "totally" joking when he said that. The amount of resistance to lambdas in the Java community is somewhat disturbing.

Yeah, most of the other JVM languages have closures, but there's still no semi-official successor to the Java language and there's always going to be the canonical platform language.

Can you post an mp3 of this?

That is on our backlog (for all our videos) but not something that we will get to in the short term. Thanks for the suggestion. Floyd

great post. Now that we know that were not getting closures for java 7 what do you think the chances are for java 8?

> great post. Now that we know that were not getting closures for java 7 what do you think the chances are for java 8?

Well gee. Do you mean the chance of closures in java8 or chance of java surviving into java8? 8-o

Semi-seriously, if java7 is end of 2009 then based on history we're looking at java8 in 2012. With every other language having lambda expressions in some form we're not going to get students coming through Comp-sci courses with java training - educational facilities are far more likely to look forward to other languages for their students. If any evidence arises of a shrinking java developer population then java will be fighting for survival.

Damn shame but I think the java-closure nay-sayers may have made themselves a very uncomfortable bed in the longer-term. "Oh we just want to keep using java not this new language called java+closures... Hey where'd java go?"

It's probably worse than what you're forecasting. I don't think Java 7 will be out until sometime 2010. And I would give another 3 years after that for Java 8. So when all is said and done, Java 8 gets closures, your average shop developer will be able to use them in about 2014-2015 (add another year or two for the release to sink in). At least we'll have replicants and stuff by then ;)

> your average shop developer will be able to use them in about 2014-2015

Likely 2015+ for many. It takes a couple of years for libraries to catch up and to find alternatives for those few libraries that have inevitably dropped in forward momentum - then there's the actual transition.

We only went to Java5 24 months ago and made the NOP transition to 6 about 6 months ago. The probability that it will be 6+ years until we move to closures support in java is plain depressing.

The move itself though from 1.4 to 1.5 was easy with a weeks effort for an 8500 source file codebase to move over, reduce some warnings and pass testing. another 6 months of gradual moving forward of APIs to use generics, varargs, enum signature affecting features. I think the nay-sayers are far too negative about how hard taking closures on-board will be.

Our company has a mix of C++, .Net and Java shops, I expect the proportion that select java ongoing to reduce.

Hi,

BigDecimal is NOT written in REXX. It is written in plain Java on top of BigInteger.
You can jump right to the source in Eclipse, IntelliJ or whatever Development tool you fancy.

Mike

Yes, I suspect around 2015 too. That’s very depressing. I find equally depressing when language engineers tell the community to go and use other languages on the VM that have closures (Groovy, Scala, JRuby). It’s certainly a welcome invitation to investigate another language .. but whose to say that it will be a language on VM? Furthermore, getting management on board with an entirely new language is just not that easy – that’s the reality of Groovy, Scala and JRuby which are all great additions to the VM. What I would like to see is some sort of cohesive plan on how Sun sees Java in the next 5+ years – a road would be nice.

Just to expand on what I think you're getting at, the JVM will always need the canonical platform language. Groovy, Scala, JRuby....I just doubt one of those will be it. Groovy would probably be the best candidate, but it takes major players (IBM, Google, Sun (if they're still around) to get on board, and even with Groovy's joint compiler, I doubt Groovy as a pure dynamically-typed as it is now, will ever get very broad support - I could be wrong here too. I think what we need is a statically-typed (at least optional) Groovy. Or maybe when Boo gets ported to the JVM, it can be an alternative.

Where is IBM, Google, Redhat, and others in all of this? Does Java need a new steward?

Here are a few points on which I differ with the presentation:

(1) Java is not there to serve the JVM: it's the other way around. That some piece of functionality is being added to the VM does not mean it should be added to the Java programming language. We have to decide, for each feature in question, whether it makes Java a better language. If so, we should add it; if not, we shouldn’t. But for heaven’s sake, let's not add a feature to the Java programming language just to make it “a better lingua franca.” Java's primary purpose is not to be a lingua franca for other JVM languages, but a language in its own right.

(2) The claim that BGGA “doesn't really change the Java type system” is false. It is a major change to the type system that affects the grammar, library APIs, conversions, annotation locations, method resolution, reachability/definite assignment, class file format (unless you want cryptic API documentation, tools (javadoc, IDEs, etc.), reflection, serialization, and who knows what all else.

(3) Doug Lea, the author of the fork-join framework, does not think that BGGA closures would improve the framework. Support for non-local returns and the ability to close over mutable local variables, in particular, are harmful in this context.

(4) The claim that “once people learn BGGA they'll find it's no big deal” is highly suspect. I heard the same thing said about wildcards, but that turned out to be tragically false.

(6) The claim that Java should add labmdas because most other languages have them is dubious. One list of popular languages can be found here: langpop.com/. Take it with a grain of salt, but the first graph says the ten most popular languages are C, Java, PHP, C++, Visual, Basic, Perl, Python, C#, Delphi. To the best of my knowledge, you have to go to the eighth position on the list (Python) before you get to a language that could reasonably be said to support lambdas. Some languages have recently added support for labmdas or are about to do so, but it is yet to be determined whether these additions will be viewed as improvements. Moreover, "all the other kids are doing it" is the worst reason to do anything. The question is, is it the right thing for this kid to do?

(7) BigDecimal was not written in REXX; it’s in Java.

I have nothing against functional programming. Anyone who has read Effective Java knows that its tenets are central to my approach. But that doesn't make functional types right for the Java programming language.

I don't want to get into a prolonged debate about this, so I'll leave it at that.

Josh

Josh,

This is probably a stupid question, but have you at some point in your career used closures in your day to day programming tasks in ~a~ language?

The reason behind the question being that I'm wondering if this is a case of you being chased with green eggs and ham or if you have legitimate reasons for not liking closures that we don't understand.

Though they have more traditionally been found in functional languages, I can't help but think the reason for it is the normal "incremental improvements" that seem to happen between generations of languages. Isn't great art / music / anything creative usually based on taking the good things that you've seen somewhere else and incorporating them in to whatever you are creating?

The basic argument that I see coming from your end is that you just aren't sure about their addition, which is not the most concrete argument to stand behind imho. Maybe I'm missing something.

I don't think Josh was building a case against closures in Java. He's just pointing out that the justifications for adding closures are not entirely correct as presented. He makes a fair point.

I have used closures from early 90'ies and written tons of software that uses them. IMHO they are sometimes useful but I think people are just hyping this stuff way too much. Java can live without them and I am certainly not going to miss that feature, and I never did.

Jesse,

Hi. I have used closures in my day to day programming tasks, though not for quite some time. I understand their benefits, and I like them. If I were designing a language from scratch it would almost certainly have closures in it. But we are most definitely not designing a language from scratch. A language is a delicate thing, as we discovered the last time we added a bunch of features to Java. For my arguments as to why BGGA closures would harm Java, see this presentation: www.parleys.com/display/PARLEYS/The+Closures+Co....

Regards,

Josh