I want closures “bolted on to Java”
Published by peter October 11th, 2008 in closures, java.After seeing Blochs' session on Javapolis last year and some of the Java 7 sessions at JavaOne this year I gave up on closures in Java. I just didn't believe that they would be part of Java 7 anymore. I also had my doubts on the 'quircks' of the BGGA proposal.
Playing around with the BGGA prototype changed my opinion though. It might not be as concise as closures in Ruby, but it _is_ a really useful extension of the Java language.
The following code I wrote runs fine with the BGGA prototype:
-
package com.finalist.closures;
-
-
import java.util.*;
-
-
public final class ClosuresExample {
-
-
public static void main(String[] args){
-
List<String> words = toWords("altijd is kortjakje ziek");
-
Collections.sort(words, {String a, String b => b.compareTo(a)});
-
System.out.println(words);
-
List<String> wordsContainingK = select(words, {String it => it.contains("k")});
-
System.out.println(wordsContainingK);
-
}
-
-
public static <T> List<T> select(List<T> list, {T=>boolean} filter) {
-
List<T> results = new ArrayList<T>();
-
for (T t : list){
-
if(filter.invoke(t))
-
results.add(t);
-
}
-
return results;
-
}
-
-
public static List<String> toWords(String input){
-
return Arrays.asList(input.split("\\W"));
-
}
-
}
This is just one example, you can do _much_ more with the BGGA proposal. It integrates with the existing API. I like this. I want this. I feel a bit sad about the fact that it might not make it to Java7.
But...
Yesterday @headius / Charles Nutter came up with a very interesting idea on twitter:
@danny_l Gafter made the same mistake; I don't mean a forked Java any more than Groovy is a fork. I want a "mostly Java" with closures.
or the reply by @danny_l / Danny Lagrouw:
@headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful
That really is what I would like to see as well. Can't we have some sort of bytecode preprocessor to make the BGGA prototype work on any modern Java version? I mean scala, Groovy and JRuby have closures and produce valid bytecode!
I would even like to help and put effort in it. Although I don't really know where to start.
See this discussion on the JavaPosse Group Group: a proposal to support cleaner syntax for Java using a two-way conversion process: http://groups.google.com/group/javaposse/browse_thread/thread/bf6cfc65fdf8fee4
Cheers
Patrick
Thanks Patrick, for pointing out that discussion! I do also think that the syntax could be a bit more clear than the BGGA solution; the BGGA synthax would however be good enough for... anything as powerful but more concise would be a bons.
I've been thinking along the same lines. Have a very simple, minimalist extension which adds closures of some sort. Make it available as a command line tool, provide an ant task, get eclipse and netbeans to recognize it.
Better yet (and certainly more controversial), create a way to deal with custom pre-processors (or macros). Let people distribute syntax extensions/translations the way jars are shared. Perhaps one out of 500 will be worth using...but it will open java up to a lot more experimentation.
Experimentation yes, but also segmentation. If such a fundamental change to the way API's are written (see ForkJoin Framework with and without Closures...) is done to Java, then it needs to be discussed in its depth, made consistent as well as easy and reside directly inside the JDK.
People are always afraid of change, but change is necessary to remain let alone to grow. I miss not having C# style properties in Java, i dont like the boilerplate code of anonymous inner classes for simply passing some lexically scoped code around. I dont like the lack of type inference and the resulting type duplication when using generics extensively. These things should be fixed.
Nothing is too late for JDK7. Some people are still on JDK 1.4 and start new projects with JDK 5 only. It is going to take some time till JDK6 is widly adopted. There is enough time to make a big and healthy step with JDK7.
Java desperately needs new language features. It needs a realistic ability to compete with C#.
The problem is: what is the point of a language feature, if the API stays the same?
An example of such inconsistency is PHP: One can do OOP in PHP, but when the API itself isn't OOP, it's uncomfortable. (PHP sucks anyway, most inconsistent 'programming' language).
The API should act as an "example of good development concepts".
Typical scenario: "Hmmm, what's that language feature for? Hey, I just search the API and see how it's used there."
Break compatibility! Make Java 8
New features plus an API that uses them.
I think that the closures proposals illustrate that you don't _have_ to change the API:
this works for all API methods eating single method interfaces. This is a good start; API's will follow later.
Peter,
In order to get more powerful use from the new resources, some changes must be made in API. An example is your select method that could be part of the API. There is a lot of places where methods could be added to get advantage from new language features. Maybe, a required complement to Closures is Extension Methods (http://msdn.microsoft.com/en-us/library/bb383977.aspx). So, we will write code like this:
import extension java.util.CollectionsExtension; // I'm just illustrating my point here.
List wordsContainingK = words.select({String it => it.contains("k")});
Wow, almost Groovy, huh?
I can see a case for shorter syntax; but I don't see why we have to have all the baggage of the BGGA closure, it creates another 'thing' that gets boxed by a closure conversion in a similar manner to how primitives are boxed. (Actually two new 'things', either a restricted or non-restricted closure.) The examples given would be just as good with inner classes that had a short syntax. Inner classes are also more powerful; since they have two this pointers, one to the enclosing scope and one to their inherited scope.
What is the advantage of new semantics that are less powerful than those we already have?
@Marcos Silva Pereira
Yes extension methods (or mixins) are something I'd like to have as well. It would reduce the need to change existing API's.
@Howard Lovatt
Nobody said we would be _removing_ Inner classes. The limitation I see with Inner Class classes is actually the scoping of context variables. I know the CICE proposal wants to address just this by doing minor adjustments. I would however prefer a more concise syntax.
@Peter,
If people want read/write access to a variable then add it to inner classes along with short syntax for instances of an anonymous inner class. What I object to is something that isn't an object and has different semantics that are going to be at best different than the rest and at worst just plain confusing.
What are the advantages of the different semantics, particularly the restriction that a BGGA closure doesn't inherit?