His withLock example reminded of my newly updated DB Connection Pooling in Ruby. I think it's short enough to fit in this forum:

require 'thread'


module DR
  
  @pool_semaphore = Mutex.new
  @pools = {}
  @default_pool_conf = {:max => 10, :counter => 1, :timeout => 60 * 30}
  @pools_confs = {}
  
  def DR.pool_cycle ds, &block
    iface = ds.interface
    iface_sym = iface.symbol
    pool_key = [iface_sym, ds.db_str].inspect
    @pool_semaphore.synchronize{
      pool = @pools[pool_key]
      if not pool
        @pools[pool_key] = {iface => Time.new}
        h = @default_pool_conf.clone
        @pools_confs[pool_key] = h
      else
        conf = @pools_confs[pool_key]
        keys = pool.keys
        if k = keys.find{|k| not pool[k] or pool[k] + conf[:timeout] < Time.new }
          iface = k
          ds.interface = k
        elsif conf[:counter] >= conf[:max]
          h = pool.invert
          oldest = h.keys.sort.last
          iface = h[oldest]
          ds.interface = iface
        else
          conf[:counter] += 1
          db_str = ds.db_str.clone
          ds.interface = iface_sym
          iface = ds.interface
          iface.db_str = db_str
        end
        pool[iface] = Time.new
      end
    }
    iface.commit
    if block
      block[iface]
      DR.pool_return ds
    end
    iface
  end

  def DR.pool_return ds
    iface = ds.interface
    iface_sym = iface.symbol
    pool_key = [iface_sym, ds.db_str].inspect
    @pool_semaphore.synchronize{ 
      @pools[pool_key][iface] = nil if @pools[pool_key][iface]
    }
  end
  
end

This is still very new (a couple of days only) and can grow in features over time. I did have some ideas of adding something like "withLock" more generic, but in Ruby it seems that that is unnecessary, being better to enjoy the delegation for each different algorithm/library.

I hope this helps in giving some perspective to a very unusual subject.

Nice, but several years too late.

Well, good proposal. Closures are necessary in programming. But Java is getting bloated...perhaps a new language should emerge, one that's based on functional programming but with enough freedom to easily do things?

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

Note that the definition of 'closures' is not synonmous with anonymous code blocks. Other languages use the term 'lambda expression' to mean an anonymous block of code; there's some strong opinions against confusing the semantic concept of a closure with the syntactical structure used for defining an in-line function.

There's more discussion on this, including input from other language designers and functional systems, hosted on EclipseZone

http://www.eclipsezone.com/eclipse/forums/t86911.html

Alex.

My great hope is that folks responsible for the future of Java restrain themselves from adding unnecessary and cumbersome symbols. (i.e., '=>' and things of that nature)

Why can't we just rewrite the closure as such:

{ (int x, int y) x + y }

or

{ int x, int y { x + y } }

or better yet, why not simply simulate the traditional method call, thereby underscoring the fact that closure is essentially a nested method, thus its parameter declaration and scoping should resemble the familiar method syntax.

(int x, int y) { x + y }

Why introduce all these new symbols? Java is a clean language, adding two-character symbols for something which can be easily expressed using parenthesis or braces is not buying any "character savings", and does not facilitate familiarity for newcomers.

Whats with the symbol love?

{ int x, int y => x + y }

In my opinion, its not clean. If one were to use the colon, it might be better, but then again, why not just use the tried and true method declaration syntax?

I've posted this to Neil Gafter's blog, but apparently either the moderation system malfunctioned, or this proposal
didn't pass the censor.

I have some doubts about the propositions, it looks for me inconsistent.

What will hapen if I define code like that inside my method:


void initListeners() throws SomeException {


void addListener(ItemSelectable is) {
is.addItemListener(
{ ItemEvent e => if (...) throw new SomeException(); }
)
}
}


The problem is, that closure may be executed after the end of execution of the enclosing method.

If the closure will be executed after the method
initListeners() will be finished, what will happen to the SomeException thrown from inside the closure?

It can not be just thrown to the Swing's API, because it didn't expect the checked exception of this type after calling itemStateChanged method from ItemEventListener interface.

Is there any planned way to inform compiler that a specific closure can not throw Exception (or return a value), because it might be executed after the end of execution of enclosing method? I do not see a clear way to enforce that rules by the compiler.