Update 2014-02-09:
JDK 8 introduced lambdas (anonymous function expressions) which allow you to solve it like this:
Function<String, String> trible = s -> s+s+s;
System.out.println(trible.apply("X")); // prints XXX
(JDK 7 and below)
No, Java does not support “directly” nested methods. (Most functional languages do though, including some JVM languages such as Scala and Clojure!)
Just for reference though; You can define local classes (classes within methods) so this does compile
class SubFunction {
private String drawTribleX(){
// *** move trible(t) inside drawTribleX() ***
class Trible {
private String trible(String t){
return t + t + t;
}
}
return new Trible().trible("X");
}
public static void main(String[] args){
SubFunction o = new SubFunction();
System.out.println(o.drawTribleX());
}
}
Note though that there are some restrictions on local classes
3.11.2. Restrictions on Local Classes
Local classes are subject to the following restrictions:
A local class is visible only within the block that defines it; it can never be used outside that block.
Local classes cannot be declared public, protected, private, or static. These modifiers are for members of classes; they are not allowed with local variable declarations or local class declarations.
Like member classes, and for the same reasons, local classes cannot contain static fields, methods, or classes. The only exception is for constants that are declared both static and final.
Interfaces cannot be defined locally.
A local class, like a member class, cannot have the same name as any of its enclosing classes.
As noted earlier, a local class can use the local variables, method parameters, and even exception parameters that are in its scope, but only if those variables or parameters are declared final. This is because the lifetime of an instance of a local class can be much longer than the execution of the method in which the class is defined. For this reason, a local class must have a private internal copy of all local variables it uses (these copies are automatically generated by the compiler). The only way to ensure that the local variable and the private copy are always the same is to insist that the local variable is final.
So, as you can see, your first option (without nested methods) is preferable in these situations.