The Artima Developer Community
Sponsored Link

Articles Forum
Considering Closures for Java

19 replies on 20 pages. Most recent reply: Feb 10, 2007 11:33 PM by Neal Gafter

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 19 replies on 20 pages [ « | 1 ... 12 13 14 15 16 17 18 19 20 | » ]
Patrick Wright

Posts: 15
Nickname: pdoubleya
Registered: Jun, 2005

Re: Considering Closures for Java Posted: Dec 22, 2006 12:56 AM
Reply to this message Reply
Advertisement
I'm all for this proposal. The biggest advantage I can see is not that we'll (just) be able to write closures to support, for example, using and freeing resources, but that the Java language can be extended along certain lines without waiting for the fairly long release cycle to approve and produce something new. It should also take some pressure off the compiler writers, in that some features which previously would require a language change can, in some fashion, be accomplished with closures. Neal already pointed this out, I'm just agreeing this is one great aspect of the proposal.

I expect there will be some wacky uses of this, and libraries for specialists, but I'm not really worried about language fragmentation or dialects. For one, those of us who end up using more general-purpose libraries than we write, it's to our advantage if those who write general-purpose libraries can create and extend those libraries with less code and less effort. Also, it may keep the Java tent open, welcoming more people into the community (or encouraging them to stay).

I also expect that, as with annotations, we'll see some leading-edge closure libraries coming out of the open-source world, with some being folded back as "standard" closures shipped with JDK 8 and beyond.

I am a little concerned about how the syntax will actually read once it's done. With generics, the very simple use-case (avoiding a cast to a variable) is very clear, but in practice I see people struggling with how to write generic methods and classes, and a great deal of frustration with the more complex cases; many times you have to search around to find someone who's run that gauntlet to explain what the heck is going on. I hope we can avoid that with closures. The good news is, with a free-speech javac we can have experimental versions of this sooner rather than later, and find out what it looks like in practice. That's already happening with local variable type inference, and I think it's a great thing.

As far as just starting a new Java--I think this calls for a much wider (and deeper) discussion. The number of languages that run, or at some time ran, on the JVM is humbling when you then remember that you've neither heard of, or used, the vast majority of them. My guess is that J6 and the scripting API will help, but I'm still waiting for a general-purpose solution that lets me:
// in Java
val = new SomeOtherLanguageObject().calculate(...);

using a bridge to instantiate and communicate with other languages is not just sub-optimal, it's a dead end for large-scale integration (or many integration points). If I can easily include multiple languages in one project, from the same IDE, I'll be more willing to explore.

Last, serious kudos to Neal for taking the heat as the public face of this closures proposal. While there were have been some good criticisms (or at least reasonable critical positions) put forward in the JL discussions, there's also a lot of people who are just plain mean.

Neal, we're with you, man. You rock. Don't stop thinking about tomorrow.


Patrick

Flat View: This topic has 19 replies on 20 pages [ « | 12  13  14  15  16  17  18  19  20 | » ]
Topic: Refactoring the EJB APIs Previous Topic   Next Topic Topic: Spring Clustering with Terracotta


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use