=== [[InvokeDynamic|Method Handle]] ===

{{:InvokeDynamic}}

=== [[Closures]] as innerclasses ===

The typical expectation for implementing [[closures]] (for example the [http://javac.info/closures-v06a.html 0.6a version]) seems to envision a closure as an innerclass (if it says at all, how [[closures]] shall be implemented), with simplified syntax. This is indeed possible, yet ineffective. Overhead of defining new (inner) class in [[Java]] is high. Each class occupies a single .class file and these files are selfcontained. They contain not only their code, but also all their static linking information (e.g. the constant pool). This information gets copied with each inner class. Splitting one class into three does not keep the final size proportional to the original one. Imagine you want to rewrite following code:

<source lang="java">
class SayHello {
public void sayHello(String to) {
String hello = "hello";

System.out.println(hello);
System.out.println(to);
}
}
</source>

so that each of the printlns runs under some lock (let's expect there there is some static method withLock(Runnable) and that we can use some form of [[closures]]):

<source lang="java">
class SayHelloSafely {
public void sayHello(String to) {
String hello = "hello";

withLock({ System.out.println(hello); });
withLock({ System.out.println(to); });
}
}
</source>

Due to power of [[closures]] this code is as simple as the original one (just the call to ''withLock'' is added, but that was intended change to satisfy our goal). However if we stick with the originally planned implementation of [[closures]] as inner classes, then the above code in fact means:

<source lang="java">
class SayHelloSafely {
public void sayHello(final String to) {
final String hello = "hello";
withLock(new Runnable() {
public void run() {
System.out.println(hello);
}
});
withLock(new Runnable() {
public void run() {
System.out.println(to);
}
});
}
}
</source>

Even this simple example shows how ineffective trivial implementation of [[closures]] can be. Instead of one class, we have three. Each of them having significant overlaps in their constant pools. Given the expected proliferation of closure based [[API]]s (as they are easy to use, much easier than innerclasses), this can lead to enormous and unnecessary waste of memory. As one who watches over [[performance]] of [[NetBeans]] I cannot silently let this happen.

=== The Mapping ===

Thankfully there is a cure. It is possible to write well performing implementation of [[closures]] using [[invokeDynamic]] and its method handles. Imagine that the above code is rewritten to use method handles (and that the withLock method now takes MethodHandle):

<source lang="java">
class SayHelloEffectively {
private static MethodHandle first;
private static MethodHandle second;

public void sayHello(final String to) {
MethodHandle addThis = MethodHandles.insertArgument(first, 0, this);
withLock(first);
MethodHandle applyToAndThis =
MethodHandle.insertArgument(MethodHandles.insertArgument(second, 0, to), 0, this);
withLock(second);
}

private void firstRunnable() {
final String hello = "hello";
System.out.println(hello);
}
private void secondRunnable(String to) {
System.out.println(to);
}

static {
first = MethodHandles.lookup().findSpecial(
SayHelloEffectively.class, "firstRunnable",
MethodHandles.methodType(void.class)
);
second = MethodHandles.lookup().findSpecial(
SayHelloEffectively.class, "secondRunnable",
MethodHandles.methodType(void.class, String.class)
);
}
}
</source>

Please accept my appology for the above use of method handling [[API]]. It is just a sketch of the implementation. I have not found the javadoc to verify or even compile my code against it. Anyway it is clear that this conversion of [[closures]] is very constant pool friendly. Regardless of the amount of [[closures]] in a class, just one, shared constant pool is used. This avoids useless duplication of its entries in the inner classes.

The method handle solution shall also be well performant. Method handle combinators are supposed to be effective. The only slow operation is the reflective binding, but that happens just once, when the class is loaded (or the method is first used).

Also notice that this approach really supports [[closures]]. If a piece of code references some variable from outer block, it is easy (because of method handle combinators) to pass such variable into the closure method via an argument. Sort of like partially applied functions in high level languages.

Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.