Java language - method adaption

BGGA Closures has been following one course to address the verbosity of defining an inner class in Java. In this blog I want to consider an alternative that could be more useful in some circumstances.

Method adaption

Consider a long running task that will use the Java 5 executor framework (I could also have used a swing example):

public void init() {
  executor.execute(
    new Runnable() {
      public void run() {
        // lots of code to run in the executor
      }
    }
  );
}

The problem is that frequently, the code to be run gets quite long. So, what may happen is that the code is refactored. One refactoring is to use top-level classes, but lets consider the simpler alternative - method refactoring:

public void init() {
  executor.execute(
    new Runnable() {
      public void run() {
        processTask();
      }
    }
  );
}
private void processTask() {
  // lots of code to run in the executor
}

However, the developer is really having to do a lot of tedious drudgery to achieve the goal here. Could it be simplified? Perhaps we could use method literals:

public void init() {
  executor.execute(this->processTask());
}
private void processTask() {
  // lots of code to run in the executor
}

So, two things have happened here. Firstly, a method literal has been used - this->processTask(). This represents the processTask() method on this specific object.

The second thing that has happened is that an adaptor has been generated for us. This is a new class that implements Runnable, and calls processTask() from the run() method exactly as we would have if we coded it ourselves.

Obviously, there is a restriction that the method signature of processTask() must match the method signature of Runnable.run(). But that seems perfectly reasonable.

My one reservation is whether too much information has been lost with this. (The choice of Runnable is being inferred in the example.) One variation is to explicitly specify the API and method that is to be adapted to:

public void init() {
  executor.execute((Runnable->run()) this->processTask());
}
private void processTask() {
  // lots of code to run in the executor
}

Here in this variation, the 'cast' is specifying the method signature to be adapted to, again using a method literal (this time not tied to a specific instance). This is a more general syntax, as it also allows assignment to a variable:

public void init() {
  Runnable r = (Runnable->run()) this->processTask();
  executor.execute(r);
}
private void processTask() {
  // lots of code to run in the executor
}

The advantage of this variation is that it handles cases like MouseListener where there are many possible methods to adapt to. This disadvantage is that there is more code which could be inferred.

But which of the two variations works best? Or perhaps the first is just a special case of the second? And is a 'cast' the appropriate syntax here?

Summary

Method adaption could be a useful language change. It certainly doesn't compete with BGGA closures for raw power, but it does provide an alternative for many async use cases that could be viewed as being a lot clearer.

As always, please view this as a concept for discussion (and its certainly not a new idea) I've not proven it can be implemented, but there's nothing obvious hitting me yet. As such, all opinions are welcome...