I have read 'Neal Gafter'!
More exactly, I read the presentation he made on Closures in the last Javapolis, and the latest version of their specifications (see last ticket "bulk" of writing). Finally I have also read a fairly recent interview: Considering Closures for Java.
And I must say, like Vincent, now that I see all the best interest of these closures!
And I will try to submit it so succinctly.
A syntax a bit strange at first
The Closures allow to define a kind of "function" when reporting variable parameter or attribute. This may take the following form:
(Int, int => int more =) (int, int b => a + b);
Our "type function takes two parameters input type int, and return an int. Its implementation is content when it return the sum of its two parameters.
Specifically, the compiler will replace this type of code by the generation of an interface and an anonymous class, which would eventually write this:
(interface Closure1
public int invoke (int i, int b);
)
Closure1 new Closure1 more = () (
public int invoke (int i, int b) (
Return a + b;
)
);
Note: in reality the interface and class anonymous generated are somewhat more complex because they use massive Generics ... but it provides an additional unnecessary complexity to the general understanding ...
Our "type function" is actually an object as another, you can use it simply:
int plus.invoke result = (5, 10);
What it brings?
As such, we must admit that the interest is fairly limited. Indeed, the closures do all their senses only when they are used as a parameter of a method: they allow to pass code as a parameter.
Currently, we use an interface that describes a method to be executed, as is the case, for example, the method SwingUtilities.invokeLater () which uses the Runnable:
SwingUtilities.invokeLater (new Runnable () (
public void run () (
doSomething ();
)
));
By using the closures could use the following code much less verbose:
SwingUtilities.invokeLater ((=> doSomething ()));
Indeed, the conversion of closures in interface / class anonymous can generate a limited class of a type consistent with the type required by the "old" API. In this specific case, the compiler will replace the closure by an object type Runnable.
We must of course comply with a number of coercion (the interface should have only one method, the parameters must be matched, and so on.), But it already allows for a simplification of writing anonymous classes while maintaining compatibility absolute (compiler "write" the anonymous class to your place).
But the specifications go further, because it can further simplify the script to make him take the following form:
SwingUtilities.invokeLater () (
doSomething ();
)
It can be found here with a code much more pleasant to read, which corresponds more to writing a block than a class anonymous.
This could help extend the API to replace some rather complex structure or redundant ...
Take as an example API to Java 5.0. If it proves to be very efficient and powerful syntax for using these locks is rather wordy:
Lock l = ...
l.lock ();
try (
doSomething ();
) Finally (
l.unlock ();
)
With the closures could be greatly simplify this:
Lock l = ...
withLock (l (=> doSomething ()));
Or even more directly:
Lock l = ...
withLock (l) (
doSomething ();
)
Even better! In this example, the closure does not use any type setting, but it is of course possible to use!
Take the case of a method with () that would use a Reader input, which would have increased the closure before being properly closed (in a block finally, for example). Its use could for example:
with (Reader in (=> doSometing (in)), new FileReader ( "filename"));
But it is also possible to use the short form using a syntax close the loop for extended:
nomDeLaMéthode (paramètres_de_la_closure: autres_paramètres_de_la_méthode) (
code_de_la_closure
)
This would:
with (Reader in: new FileReader ( "filename")) (
doSomething (in);
)
Another interesting example: the course elements of a Map. At present, and despite the use of the loop for extended it remains fairly binding:
Map <Key,Value> map = ...;
for (Map.Entry <Key,Value> entry: map.entrySet ()) (
Key k = entry.getKey ();
Value v = entry.getValue ();
/ / Using k, v
)
With the closures it could take a more sympathetic:
Map <Key,Value> map = ...;
forEach (Key k, v Value: map) (
/ / Using k, v
)
What mark in this syntax is precisely that it is very close to the investigation of basic control (if, for, while).
And the rapprochement does not stop there! The code of closures may be less restricted than classes anonymous instructions break, continue and return to apply the method calling, as if it were a mere block and not calling a class anonymous. Similarly, the code of closures could directly manipulate variables scope parent!
This offers the possibility to define new type of block, and allow everyone to bring new syntax specific to each API! The closures then take all their sizes!
In the latest example, in the following code, education code in the return of the closure would mean the return of the method getKeyForValue (), and not only code from the closure:
public <K,V> K getKeyForValue (Map <K,V> map, V value) (
forEach (K k, v: map) (
if (value.equals (v)) (
return k;
)
)
return null; / / Value Not Found
)
With an anonymous class this type of construction is not possible.
Of course, the closures may also be used on a limited, meaning that they operate in the same way that the code of anonymous classes, which remains binding and / or valuable in certain cases.
Convinced?
Personally I really look forward to playing with closures. The possibilities seems to me really huge, and it could be a revolution far more important than what was Tiger's time. This promises of even more advanced APIs and simple!
Finally, for those who are interested in the subject, I can only advise their monitor's blog Neal Gafter (if not already the case)
