Consider method handles

[lukaseder]

See also: https://code.google.com/p/joor/issues/detail?id=19

[iirekm]

There are problems with this approach:

• won't work in Java 6 (there are still projects that have to support it) and Android (I guess that current joor should work there without problems)
• the biggest cost about reflection is finding method by name and calling setAccessible(true), after that it's almost as fast as regular method calls, if performance is a problem, we may consider caching of accessible() objects some day, MethodHandles also have a quite big lookup cost, so no real gain

MethodHandles may also provide automatic resolution of 'similar' methods, but it works only for methods which are visible from current code. If someone wants to call visible 'similar' methods in everyday programming then should rather consider dynamic languages like Groovy (they can use invokedynamic and MethodHandles).

[lukaseder]

won't work in Java 6 (there are still projects that have to support it) and Android (I guess that current joor should work there without problems)

We can catch NoSuchMethodError or NoClassDefFoundError in a static initialiser and see whether this feature is accessible or not. If it isn't, there's still the possibility to implement stuff with pre-Java-7 API.

MethodHandles also have a quite big lookup cost, so no real gain

Probably true

If someone wants to call visible 'similar' methods in everyday programming then should rather consider dynamic languages like Groovy

That's correct. The use-cases of jOOR are limited. We designed it mostely for integration testing. Certainly, actual method handle support is low-prio. I'll fix tags accordingly.