The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Klaus Kreft and Angelika Langer Review the Java Closures Proposals

11 replies on 1 page. Most recent reply: Jul 1, 2008 2:47 PM by Morgan Conrad

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 11 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 17, 2008 10:52 PM
Reply to this message Reply
Advertisement

Adding closures to the Java language is at the center of the debate concerning Java's future: Some believe that closures are such an important construct, supported by many other modern languages, that Java's lack of closures support would sooner or later entice developers to replace Java some other language as the workhorse language in their tool box. Others argue that adding closures would make Java even more complex, harder to learn, and that such added complexity may turn developers away from Java.

Advocates of these opposing views have produced several proposals to add closures-like syntax to Java. In a recent JavaWorld article, Understanding the closures debate, Klaus Kreft and Angelika Langer dissect the three major closures proposals from the viewpoints of complexity and expressiveness:

Closures [are] a standard feature in older languages such as Scheme, Smalltalk, and Lisp, and have more recently made their way into dynamic languages such as Ruby and Groovy. Closures are a natural fit for statically typed, functional Scala, and recently many have argued that they have a place in the Java language, too...

Many developers argue, conversely, that closures are a bad fit for the Java language. According to this camp, adding closures would be the proverbial "nail in coffin" for the already stuffed syntax of a language that tries to do too much...

The BGGA proposal started the "closures in Java" discussion... BGGA adds a lot of power to the Java language, but also a lot of complexity.

CICE stands for "Concise Instance Creation Expression," [and] is considerably less complex than BGGA and advocates an approach that is best described by its tagline: closures without complexity. In CICE, closures are essentially an alternative syntax for inner classes. CICE closures stick close to the existing Java language and do not add much new functionality...

FCM stands for First Class Methods ... is somewhere between CICE and BGGA, and is much closer to BGGA. It mainly differs from the other two proposals in how it introduces closures into the Java language: not as an isolated novel concept, but embedded into an approach that allows handling of types and references of methods as first-class elements in Java. In FCM, a closure is just a special kind of method: the inner method...

In the article Kreft and Langer summarize key points of the closures debate:

One thing all of the closures proposals agree [on] is the need to conceptually replace inner classes with a more powerful programming construct. Adding closures to the Java syntax would not mean losing inner classes; rather, the two constructs would be compatible and interchangeable. The advantage of closures, of course, is that they add flexibility and power not found in inner classes...

There is one area where the proposals differ drastically. In the BGGA proposal it is permissible for a closure to contain non-local control statements that affect the control flow of the context in which the closure is defined, not only the control flow within the closure itself... The introduction of non-local control statements distinguishes BGGA from the CICE and FCM proposals...

What's your take on the various Java closures proposals?


Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 19, 2008 7:07 PM
Reply to this message Reply
The more I understand them, the more sceptical I grow of the need for closures. From the article's goals:

"Simplify the syntax for implementing and using certain simple interfaces (with just one method), such as Runnable, ActionListener, and Comparator."

In real code, you shouldn't be using ActionListener. You should be using Action. That way text can be internationalized, buttons can have fancy icons, and, most importantly, an action be turned on and off as appropriate! Using ActionListener directly is almost always bad code.

In my experience, there are a small number (~10, and certainly <100) of Comparators you need. Best to put them as actual classes (or static anonymous classes) so they are in one place and can be reused, extended, and Unit Tested!. We often chain together comparators. YMMV I guess, but I use Java Collecitons a ton so this is based on long experience.

Many of my classes (that do algorithms) are Runnable from the start. I have no need to make Runnable easier to do, it's pretty easy already, other than catching any CheckedExceptions, which would be an issue in closures too.


Now, for their example. Sure, it's a contrived example, but Closures just aren't needed. All you need is

public class Text implements Block<integer>
 
    public static void main(String[] args) {
        List<Integer> nums = Arrays.asList(1,2,3);        
        Utils.forEach(nums, new Text());
      }
    
    public void invoke(Integer t) { System.out.println(t); }
}


Which is way clearer than any of the proposals. Now, this way fails if there are multiple invokes you want. For example, if sometimes you want to println and sometimes you want to delete the database record with that id. I hardly ever encounter this need - usually there is ONE natural method. Adding all that complexity for people who can't decide what class Text should do when invoked with an integer is unnecessary. (And, for those should be rare cases, a Visitor pattern can help)


IMO, Java should add a few new "standard" interfaces, something like

Invoke<IN, OUT>   (much like in the article) {
   OUT invoke(IN in);
}
 
 
FPMap<KIN, VIN, KOUT, VOUT> {
   Collection<Map.Entry<KOUT,VOUT>> map(KIN inKey, VIN inValue);
}
 
 
Reduce<IN, OUT> {
  OUT reduce(Iterable<IN> inList);
}


whatever else the FP people want, and let it go at that. (Maybe some Abstract classes to get people started).

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 20, 2008 9:42 AM
Reply to this message Reply
I am strongly for BGGA. Now that that is out of the way, here are some thoughts on the Closure Wars.

I do not think the presence or absence of closures in Java 7 will have much impact on the lifespan of Java. The language is used everywhere and is great at what it does. It will take at least another decade to become the next COBOL.

One question is whether the technology leaders continue to support the language because that is going to shape what the "golden years" of Java look like. The last few years have seen many declarations: "Java is already too complex" or "Java has become an abomination." These harbingers have fled to other languages, often to return, saying things like, "I don't like Java but there just ain't anything else out there." The options for enterprise grade languages are pretty slim. My hope is riding on Scala but it's too early to tell.

Another question is whether the addition of closures will make any difference for programmers. I know for a fact we an our company have many use cases and would love to have BGGA closures. But what about those who fear the addition will only make their lives miserable?

In hundreds of phone interviews with Java developers I have observed that the addition of generics to Java 1.5 has had little negative impact on programmers. Most of these developers don't use generics because their company is still not using Java 5. Of those who are using generics, almost all are just clients of generic classes such as List and Set. There are a precious few who actually understand and use generics to write classes. Most developers are not negatively impacted by generics at all.

Generics are a great data point because first, they are complex. Second, the implementation is half-ass. To the first point, the bulk of programmers who don't need generics have safely ignored them. To the second, those who make good use of them (we use them all the time) are rightly concerned that Closures are going to be another generics. CICE and FCE are the analogy to generics. BGGA is complex, but at least it is complete. Programmers who don't care or don't need to care, will blissfully continue to write their beans and take home their dough. But those who write frameworks or complex systems should care immensely and embrace the power of closures.

At JavaOne, I attended a couple of sessions where straw votes were taken on the closure proposals. It was so depressing. Most wanted to leave the language alone. Upon digging a little further - our company had sent a posse who glad handed information from the naysayers after the sessions - we learned that most people's opinions were poorly informed and fear-based. That's the state of the Java community.

One argument against closures that I think has power is that Java is so crufty it is better to walk away and start afresh. New languages are so appealing for their conciseness and expressive power. It's very alluring. Unfortunately, as I said before, there are no contenders that bring the same values as Java but in a concise, expressive package...but Scala sure looks good to me.

Some have said, "Freeze Java, let the Luddites have it, and we will create Java 3000 - the language Java was always meant to be." Whatever the outcome, with all its problems, Java is still to most reliable, powerful, and productive enterprise class language available. It will be around for a while. I personally just hope it gets full-fledged closures as soon as possible.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 20, 2008 12:30 PM
Reply to this message Reply
> One argument against closures that I think has power is
> that Java is so crufty it is better to walk away and start
> afresh. New languages are so appealing for their
> conciseness and expressive power. It's very alluring.
> Unfortunately, as I said before, there are no contenders
> that bring the same values as Java but in a concise,
> expressive package...but Scala sure looks good to me.

The problem with Scala is that it's a very complex language to understand fully. You can use it without totally understanding (like I do) but this is unsettling to me. A lot of time can be wasted trying to figure out why code is not behaving as expected. You can't just assume you'll never need someone who understand the more esoteric points.

I think Scala fills a niche for the JVM/CLR but that's not the same niche that Java has filled.

> Some have said, "Freeze Java, let the Luddites have it,
> and we will create Java 3000 - the language Java was
> always meant to be." Whatever the outcome, with all its
> problems, Java is still to most reliable, powerful, and
> productive enterprise class language available. It will be
> around for a while. I personally just hope it gets
> full-fledged closures as soon as possible.

That's my vote. What's unfortunate is that this wasn't done prior to the inclusion of generics. There's no perfect solution to this issue. I think it's a good lesson for the designers of future languages: it's a lot easier to not add a poorly thought out features than it is to remove them later. The designers of Java had generally been very careful about what was added. It's unfortunate that they appear to have had a crisis of confidence with regard to generics and shoehorned in that design when it was obviously not good.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 25, 2008 6:17 PM
Reply to this message Reply
Sean - could you elaborate on a few of your use cases? Especially in light of my comments where I somewhat over-boldly claim that there are very few good use cases :-).

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 25, 2008 6:39 PM
Reply to this message Reply
Sure. The most common case is when we want to do <something> and then always do another thing like closing a DB connection, or execute a transaction, etc. We do this kind of thing a lot in framework code and <something> is in the form an anonymous inner class that implements Runnable.

The obvious advantage of closures would be concise expression of <something>, but we could go a lot further than that and create a library of higher order functions that implement common business logic.

To one of my points, the consumers of the framework have an elegant way to safely and uniformly perform a rich set of common operations. The complexity is tucked away and implemented by folk who are trained to deal with it.

We use java.util.concurrent quite a bit and much of that could be simplified and made more flexible through closures too.

Hope that helps. It's off the top of my head. I can think of a dozen times when I or one of my colleagues have exclaimed, "This would be so much nicer if Java had closures!"

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 25, 2008 7:20 PM
Reply to this message Reply
Thanks Sean. I worked on a similar "mini framework" around DB queries that did all the closing, etc...

My question is do you really want these "little" Runnables as closures, which are non-reusable, non-extensible, and non-unit testable, or do you want them in a class?

For example, if your query returns a ResultSet, and you want to convert that to a List of Foos, I would greatly prefer that Foo implement an interface

public interface FromResultSet {
Foo createFromResultSet(ResultSet rs);
}

and then some subclass of Foo that adds one column could reuse most of Foo's code. The alternative with closures is
just plain worse. (For the record, I'm not a big fan of anonymous classes either, they are just as bad as closures and reqire more work!)

Unfortunately, in this case what you really want is either a static method

Foo Foo.createFromResultSet(ResultSet) or a constructor
Foo(ResultSet)

neither of which Java supports cause interfaces can't define constructors or statics. There are workarounds, but, IMO, Java would be much better served by allowing interfaces to define contructors or statics, something that should be understandable to most programmers, than to implement closures, something that is less understandable.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 25, 2008 7:35 PM
Reply to this message Reply
> Thanks Sean. I worked on a similar "mini framework"
> around DB queries that did all the closing, etc...
>
> My question is do you really want these "little" Runnables
> as closures, which are non-reusable, non-extensible, and
> non-unit testable, or do you want them in a class?

They are not necessarily little.
If they are first class, then they are testable and reusable. This is why I support BGGA.
If they are classes, they become quite unwieldy.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 25, 2008 7:38 PM
Reply to this message Reply
> > Thanks Sean. I worked on a similar "mini framework"
> > around DB queries that did all the closing, etc...
> >
> > My question is do you really want these "little"
> Runnables
> > as closures, which are non-reusable, non-extensible,
> and
> > non-unit testable, or do you want them in a class?
>
> They are not necessarily little.
> If they are first class, then they are testable and
> reusable. This is why I support BGGA.
> If they are classes, they become quite unwieldy.

I should add that the user of the API can choose to create a first class closure, or do an in-line call as would be done with an AIC. In that case, which is what I think you are concerned about, then the unit under test would have to be some surrounding object. That's usually the case.

Jesper de Jong

Posts: 6
Nickname: 56437
Registered: Jun, 2008

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 28, 2008 9:46 AM
Reply to this message Reply
I had not really looked in-depth at the Java closures proposals until recently, and heard about the article on JavaWorld. It's great article, very clear.

My position: For CICE + ARM, against BGGA.

I saw thw following talk by Josh Bloch at JavaPolis in December 2007 which really made me very skeptical of BGGA closures:
http://www.parleys.com/display/PARLEYS/Home#slide=1;talk=5210267;title=The%20Closures%20Controversy

In my opinion, closures are a fine concept in Ruby, Scala and other languages, but forcing full-scale closures into Java will make it much too complicated. I especially do not like the non-local returns.

I work in a big company with a lot of Java programmers, and the average Java programmer is not an intellectual superstar who understands all the intricacies of the programming language.

What the majority of programmers need, who have to get their job done every day, is a practical programming language without unnecessary complexity. Note that Java was originally designed to be a practical and easy programming language, and that's what played a large part in its success.

Sure, I love tinkering with programming languages, and closures are a very powerful and interesting concept. But in my opinion, BGGA closures would make Java way too complex for the average programmer.

Ivo Wever

Posts: 3
Nickname: confusion
Registered: Apr, 2008

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jun 30, 2008 2:10 AM
Reply to this message Reply
There are a precious few who actually understand and use generics to write classes. Most developers are not negatively impacted by generics at all.
I think you overlook one problem here: code may be written by experts, but needs to be understood by the lesser gods that need to maintain the code later on.

Of course, many of the difficulties are inherent to the concept of closures and, like in the case of multithreading, some developers just won't grasp the problems involved. But that doesn't mean we shouldn't try our utmost to prevent the syntax from aggravating the problem.

The Javapolis presentation by Josh Bloch, already referenced in this thread, illustrated that clearly: do we really expect an average developer to be able to maintain code that uses BGGA closures?

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Posted: Jul 1, 2008 2:47 PM
Reply to this message Reply
Just watched Josh's talk.

I think the BGGA non-local return issue is a problem, but could be handled by keeping return x as the normal, expected, local return syntax, and adding a special syntax/keyword superreturn x or nonlocalreturn x or whatever.

IMO, allowing local variables to be modified by other threads is far more fatal design flaw in BGGA. Sorry, it's a strange, totalling confusing and terrible idea.

Josh made a good point that, in many cases, just using the new Java 5 for loop saves enough typing to eliminate some need for closures. And I like his "targeted" resource allocation proposal, where you put stuff inside a try, instead of creating a general do anything framework.

Flat View: This topic has 11 replies on 1 page
Topic: Klaus Kreft and Angelika Langer Review the Java Closures Proposals Previous Topic   Next Topic Topic: New Features in Eclipse BIRT 2.3


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us