Aop/invokedynamic/interceptable


#1

Hey hey, I've been checking Kotlin for a while and so far, I like it pretty much, although I didn't experiment thouroughly with it. Anyway, one of the things I really, really miss in Java, is some kind of 'intercept a method call'. There is a way, like using proxies, but these tend to pollute your code, and JVM optimization is pretty hard, inlining is not always possible (due to big) and you get huge stack traces with all the proxy calls. There is an invokedynamic-instruction on the JVM (and callable in Java7 and later), which can be used to overcome the proxy-issues. What I wonder is: does Kotlin provide (or are there plans to provide) any kind of 'interceptable' functions, meaning, if a method is defined as interceptable, is it possible to add some behaviour before or after the method is called (without using reflection etc, which causes overhead and so on), like http://niklasschlimm.blogspot.be/2012/02/java-7-complete-invokedynamic-example.html? I remember I saw Remi Forax on Devoxx Belgium last year, and he showed some Java-code intercepting calls using the 'invokedynamic'-instruction in the compiled code. It looked more or less like this (although I can't remember fully):

public class SomeService {

  @SomeAnnotation private interceptable Field field; }


HashMap<Class<?>, Object> aspects = …
aspects.put(Field.class, new FieldImplementation());
Bootstrap.addAdvice(new Advice(AnnotatedElement ae, MethodHandle mh) {
  if (!ae.isAnnotationPresent(SomeAnnotation.class)) { return mh; }
  Class<?> type = mh.type().returnType();
  return MethodHandles.dropArguments(
          MethodHandles.constant(type, aspects.get(type)), 0, mh.type().parameterType(0)));
})


or even something like - I certainly remember the ‘public’-keyword on a field :wink: :

public class PoJo {
  public interceptable String field
}


Bootstrap.addAdvice(new Advice(AnnotatedElement ae, MethodHandle mh) {
  if (ae instanceof String) {
          Methodhandle getter;
          if (mh.type().parameterCount() == 0 && getter=getGetter(Field(ae)) != null) {
           return getter;
          }
  }
  return mh;
})

Well, something similar to the latter is actually already implemented in some way in Kotlin (properties instead of fields+getters/setters).

Anyway, the ‘interceptable’-keyword is non-exisiting in Java, but would be necessary to have some kind of intercept not using proxies or reflection-thingy. It just means: ‘you can intercept it (using the invokedynamic-instruction, although I don’t really care which instruction is used, as long at it’s not proxies and/or reflection)’ and than you need some kind of system to say how to intercept it (in this case, using annotations, but there may be another, better syntax in a new language). It would be great solution for things like security, logging and many more, and maybe there might be something to do with it concerning (checked?) exceptions - I don’t like exception handling polluting my classes, I’d rather have it separate somewhere, but neither do I like ‘not being forced to think about some important exceptions that may break the application’, but that’s another discussion.
Or is there already a (simple) way in Kotlin to mimic this kind of behaviour?

Kurt


#2

This is an interesting suggestion indeed. For new Kotlin generates byte code compatible with Java 6, so we refrain from using invokedynamic, but in the future it would be beneficial to support interceptable functions


#3

It'd be nice if it would be a basic feature, I'm actually thinking of some kind of syntax telling which classes to use to intercept a function (or class, or property, of whatever, I didn't really think it through), something like:

fun getService() : SomeService interceptedBy SecurityManager, Logger {
  ...
}

Or even make something system-wide configurable - please no xml; I don't mind writing code to configure something ;) !! - so it will behave like a kind of simple container. It might then even be used for inverse of controle-structures. In that case, there's 'one Kotlin to rule them all'; no need for Kotlin/KotlinEE and a bunch of specific 'EE-like' frameworks. Well, so far, I suppose we'll have to wait untill there's interop with Kotlin and Java7... . I suppose it (invokedynamic) will make the function-type stuff somewhat easier to implement, or make the application faster (invokedynamic seems to be faster than the extensively used proxies and/or reflection). Just out of curiosity, is there any roadmap for Kotlin?

Thx, Kurt