In this interview, Neal Gafter talks with Bill Venners about the proposal for adding closures to the Java programming language.

http://www.artima.com/lejava/articles/neal_gafter_closures.html

What is your opinion of the closures proposal?

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?

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

There's always Scala, Nice (not much development going on), and a Haskell-like language called CAL. I was a bit skeptical about retrofitting closures into Java, but after listening and watching the slides of Neal's presentation I've become convinced that it can be done in a clean manner.

The problem with "a new language should emerge" idea is where does this new language come from? Ideally, it should have the backing of a Google, IBM, or Sun. I really like the Nice language, but I know that it sitting over at SourceForge pretty much guarantees non-adoption. Scala is in active development, but it lacks good Eclipse integration. That's another show stopper for these alternative langauges on the JVM. It can be the greatest thing since sliced bread, but if it doesn't have good IDE support in this day then forget about it.

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.

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.

P.S., I'm referring to the "@pool_semaphore.synchronize{" blocks.

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 don't think it's an either-or choice. I was skeptical of adding closures to Java at this late date in the language's history, but was impressed with Neal's presentation at JavaPolis. Even though I did read the first version of their proposed spec, I didn't quite have time to study it enough to grok it deeply. Once I saw his presentation and got to ask him questions afterwords, I quite liked their proposal.

I think we should continue to try and improve Java as much as is possible at this point. I know that each thing you add adds bloat, increases surface area, so the benefit of each new feature has to outweigh the cost of added bloat. But the closures proposal I think shows it is still possible to make enhancements where the benefit outweighs the cost. I and a lot of other people will be using Java for a long time to come, and I don't think Java is good enough to freeze it at this point.

On the other hand, I also think it would be a good to foster and nourish the growth and acceptance of other languages on the JVM, and let the market decide which ones should "win." Having a stable Java might make it a bit easier for other languages to integrate nicely with Java, but still, on the whole I hope we can do a few more things to Java to ease existing pain points when programming in Java.

> The problem with "a new language should emerge" idea is
> where does this new language come from? Ideally, it
> should have the backing of a Google, IBM, or Sun. I
> really like the Nice language, but I know that it sitting
> over at SourceForge pretty much guarantees non-adoption.
> Scala is in active development, but it lacks good
> od Eclipse integration. That's another show stopper for
> these alternative langauges on the JVM. It can be the
> greatest thing since sliced bread, but if it doesn't have
> good IDE support in this day then forget about it.
>
I once heard Geir Magnussen (the guy who did Velocity and is now in charge of Jakarta at Apache) say, "Open source is not about them. It's about us." I'm not sure if he made that up. Sounds like something he might have been quoting of others. But anyway, I've been interested in Scala, and have been worried about its tool support. Not just IDE integration, but also code coverage, style checkers, static analysis tools that find bugs, etc. To compete with Java, you need to have good tool support, because Java has outstanding tool support.

But on the other hand, a lot of these tools in the Java arena are open source, and so "we" (the Scala community we) can help improve the situation. If we (the Artima we) decide to use Scala, we will surely try and help with tools to the extent we can afford to do so, because it helps us. I also was told by Eugene Vigdorchik from JetBrains that IntelliJ is working on a Scala plug-in for IDEA (he said this on the Scala mailing list). I have the feeling that those languages that do rise to the top of a free-market competition for alternative languages on the JVM, will get good tool support.

The trouble I see is more that Java-based web applications at least, are already chock full of too many languages. You've got to know various flavors of XML, especially HTML, JavaScript, some templating language (such as Velocity, JSP, or near to my heart StringTemplate), Java, maybe Flex for Flash stuff here and there. The prospect of adding another one or two (Groovy, Jython, JRuby, Scala, etc.) makes it even more of a burden on the individual developers to be multi-lingual. But honestly after soaking up the zeitgeist at JavaPolis last week, I'm even more strongly leaning in the direction of picking some other language to for hand-coding for our Java--I mean, JVM--applications. The contest for me is currently between Groovy and Scala.

Dick Ford wrote Scala is in active development, but it lacks good Eclipse integration.

Their Eclipse plugin is on version 2.4.8, what in particular does it lack?

> Dick Ford wrote Scala is in active development, but it
> lacks good Eclipse integration.
>
> Their Eclipse plugin is on version 2.4.8, what in
> particular does it lack?

Good is the keyword here, as in what you get for Java.

An specific example would have been helpful.

> An specific example would have been helpful.

Somehow I doubht that.

> An specific example would have been helpful.


Do you mean code examples of closures? If so, you can see several at Neal Gafter's JavaPolis talk:

http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java

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