The Artima Developer Community
Sponsored Link

Articles Forum
Considering Closures for Java

19 replies on 2 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 2 pages [ 1 2 | » ]
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Considering Closures for Java Posted: Dec 20, 2006 4:00 PM
Reply to this message Reply
Advertisement
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?


Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Considering Closures for Java Posted: Dec 21, 2006 2:34 AM
Reply to this message Reply
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?

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 4:16 AM
Reply to this message Reply
> 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.

Alex Blewitt

Posts: 44
Nickname: alblue
Registered: Apr, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 6:16 AM
Reply to this message Reply
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.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Considering Closures for Java Posted: Dec 21, 2006 6:52 AM
Reply to this message Reply
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.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Considering Closures for Java Posted: Dec 21, 2006 6:54 AM
Reply to this message Reply
P.S., I'm referring to the "@pool_semaphore.synchronize{" blocks.

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Considering Closures for Java Posted: Dec 21, 2006 7:42 AM
Reply to this message Reply
Nice, but several years too late.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Considering Closures for Java Posted: Dec 21, 2006 8:13 AM
Reply to this message Reply
> 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.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Considering Closures for Java Posted: Dec 21, 2006 8:29 AM
Reply to this message Reply
> 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 9:43 AM
Reply to this message Reply
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

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 12:52 PM
Reply to this message Reply
> 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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 3:25 PM
Reply to this message Reply
An specific example would have been helpful.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Considering Closures for Java Posted: Dec 21, 2006 4:14 PM
Reply to this message Reply
> An specific example would have been helpful.

Somehow I doubht that.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Considering Closures for Java Posted: Dec 21, 2006 6:56 PM
Reply to this message Reply
> 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

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
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 2 pages [ 1  2 | » ]
Topic: Refactoring the EJB APIs Previous Topic   Next Topic Topic: Spring Clustering with Terracotta

Sponsored Links



Google
  Web Artima.com   

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