BT

InfoQ Homepage Presentations Language Parity: Closures and the JVM

Language Parity: Closures and the JVM

Bookmarks
29:21

Summary

In this presentation from the JVM Languages Summit 2008, Neal Gafter discusses closures on the JVM. Topics covered include the JVM libraries, the challenges of running other languages on the JVM, language-specific wrapper/shim libraries, ways of making the JVM more language-friendly, whether lambda expressions are too hard, the history of closures, and forking the JVM to support closures.

Bio

Neal Gafter works for Microsoft on the dotNet platform languages. To balance his life, his hobby is designing and developing the future of the Java programming language. He was previously a software engineer at Google working on Google Calendar, and a senior staff engineer at Sun Microsystems, where he co-designed and implemented the Java language features in releases 1.4 through 5.0.

About the conference

The 2008 JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. The talks inform the audience, in detail, about the state of the art of language design and implementation on the JVM, and the present and future capabilities of the JVM itself.

Recorded at:

Feb 12, 2009

Hello stranger!

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

Get the most out of the InfoQ experience.

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

Community comments

  • technical problems

    by Brian Edwards /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: technical problems

    by Floyd Marinescu /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Fixed

  • Re: technical problems

    by Brian Edwards /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • VB programmers are smarter than Java programmers

    by Dan Tines /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • mp3

    by adam rabung /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Can you post an mp3 of this?

  • Re: mp3

    by Floyd Marinescu /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 presentation

    by serge ---- /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: great presentation

    by Talden - /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > 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?"

  • Re: great presentation

    by Dan Tines /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 ;)

  • Re: great presentation

    by Talden - /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > 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.

  • BigDecimal is NOT written in REXX

    by Michael Mueller /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: great presentation

    by serge ---- /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: great presentation

    by Dan Tines /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Re: great presentation

    by Joshua Bloch /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: great presentation

    by Jesse Kuhnert /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: great presentation

    by Tero Vaananen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: great presentation

    by Joshua Bloch /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: great presentation

    by serge ---- /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Josh,

    In the event that Java doesn’t get closures which I suspect will probably be the case, are you still for a clean up of anonymous inner classes? Has any additional work gone into CICE + ARM since its initial publication?

  • Re: great presentation

    by Jesse Kuhnert /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sorry about that, I guess you did have a very thorough set of arguments that I had forgotten about.

    In the context of historical data showing java5 language changes to be harmful however, I'm not really in the camp of people that have disliked the changes. Though generics were definitely weird to understand at first when attempting to create APIs that use and provide them, understanding and using existing APIs using generics has always been a breeze and definite improvement over the previous type system from my point of view. (that view being specifically not one of the people that had to suffer through implementing them in the jdk of course ;) ) Same goes for varargs / enums / etc. Somewhat awkward to use at first but almost immediately understandable and beneficial when using an API that makes use of them.

    Could the same not be true of closures? Hard to implement in API's at first (as any new concept would be), but in the end proven to be overall beneficial and time-saving for developers?

    Sorry, I know you don't want a long-winded debate about it here. Just voicing what I think isn't a minority opinion, and you obviously do hold a great amount of influence over how some of these things might ultimately be decided for java..

  • Re: great presentation

    by Neal Gafter /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A couple of notes on Josh's response:

    (1) The JVM, and the JDK, are no longer there just to support Java. If the JVM is to be described as an interoperability platform for many languages, then the platform libraries should support APIs that use common features of those languages.

    (2) Saying that BGGA is a major change to the type system doesn't make it so. The only major change to the type system introduced by BGGA is disjunction types, which Josh supports. As for many of the things he suggests it affects (serialization, reflection, etc), he's just making that up.

    (3) Doug Lea has asked to be listed as a supporter of the draft Closures JSR, of which BGGA is currently the only draft solution. Doug Lea has also publicly stated that the lack of resolution on these issues is a primary reason that the parallel arrays API has been withdrawn from JDK 7. Josh's other CICE coauthor, Bob Lee, has also asked to be listed as a supporter.

    (4) Josh's quotes from the web about difficulties with wildcards are in fact difficulties with modeling the user's domain, not the language feature itself. In one of his two quotes, the user he quoted wasn't even attempting to use wildcards nor had any problem with them. In any case, difficulties, real or perceived, about one language have little to do with consideration of another.

    (5) There is no 5.

    (6) PHP has closures in version 5.3 and later. The C++ standards committee has voted them in too. Visual Basic, the shipping version, supports closures. Perl certainly does, and most famously so, as described in the book "Higher-Order Perl: Transforming Programs with Programs" by Mark Jason Dominus. Python, C#, and Delphi do too. In short, Josh is simply misinformed about the state of the programming language landscape, and he does you, the reader, a great disservice by spreading this misinformation.

  • Re: great presentation

    by Pavel Minaev /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > 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.

    I would have to disagree with that. Perl had supported lanbdas for ages, VB has them for over a year now, and C++ is definitely getting its share in the next standard, and even PHP has create_function, ugly as that is. C obviously won't be getting lambdas, but it's just too low-level for that sort of thing. Of those below Python on the list, Delphi has lambdas, and obviously C# does as well.

    To summarize, this means that, from the entire top 10, Java is one of two languages which neither have lambdas nor considering to add them in the next version, and the only high-level language that does so. I think the concern is more about "not considering" part - this is really worrying, as it indicates excessive conservatism on behalf of language designers, rather than the desire to "do things slow but do them right".

  • Generics?

    by Alex T /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What's so wrong about generics? (besides type erasure)
    I see them mentioned every time whenever closures are mentioned.

  • Re: great presentation

    by Knox Liam /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Having looked at the CICE examples and the papers on Fork/Join I cant really see what great beneif CICE will add to this space. The current Fork/Join proposal seems infected with a disease of inner classes that add no power and just extra weight. I disagree with Bob Lees view of power/weight comparison of these two Closure proposals.


    I cannot also seriously think that Doug Leah prefers the 100's of no-value interfaces in his design

    Based on this example I am more inclined to agree with Neil's opinions rather than Bloch's.

    I think Bloch's comments on people implementing Java in a wider range(exotic) of styles has some weight but I could equally say anyone picking up google-collections will be writing in a different style of Java than your avereage junior developer This is a learning curve regardless

    I think overall addition of Closures akin to BGGA will add more power than downside to Java. Saying things like 'Move to Scala if you want Closures' is not really addressing the core problem as Java's uptake and market share relative to Scala will remain huge for, I would punt, the rest of my development life.

    Working in 'real' jobs on massive systems you dont often get a chanceto rewrite the system in the flavor of the month language. Though you benefit massively from new non breaking language features (e.g. Generics, Enums, varargs etc). This discussion shouldnt be an academic exercise it should be about would Java developers be more productive given Closures and would it make Java a more productive and powerful language.
    Based on that Closures would definetly get my vote for Java 8.

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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.