My JVM Wishlist (Part 1): Interface injection
My JVM Wishlist (Part 1): Interface injection
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Interfaces are injected in one of 3 situations:
- When a method of the interface is invoked on an object.
- When an
instanceofcheck for the interface is performed on an object.
- When the interface is queried for via reflection (I can see this working with
Class#isAssignableFrom, but I have my doubts when it comes to
Class#getInterfaces, although I'm sure someone smart will be able to solve this without having to know about all injectable interfaces beforehand).
When any of these occur, a class can either have the interface implemented already (in the regular way) or a special static injection method on the interface class is invoked. It is up to this injection method to determine if the given class can implement the interface or not. If it determines that the class can implement the interface any missing methods have to be supplied at that time. John suggests that these methods are to be supplied as method handles.
Since method handles, according to the EDR of the InvokeDynamic proposal (JSR 292), can be curried this would make it possible to attach an extra state object to the returned method handle, or to return a different implementation of the interface depending on the class they are injected to. Once an injection method of a specific interfaced has been invoked for a specific class, the injection method will never be invoked for that class again, meaning that once a class has been found to not implement an interface, that information will be final, and once an implementation of an interface has been supplied, this implementation can never be changed. This is important since it will allow the VM to perform all optimizations, such as inlining, as before.
What can this be used for?
As a language implementer on the Java platform, I think interface injection would be a blessing. In fact, I think it is the one thing that would simplify the implementation of languages on the JVM the most. Any language probably has a base interface (as Java has
java.lang.Object and Jython has
org.python.core.PyObject), let's be unbiased and call it "
MyLangObject" for the sake of the continued discussion. There are two things that make the Java platform great:
- There are a lot of really good toolkits and libraries implemented for the Java platform.
- There are a lot of great languages for the Java platform in which even more great libraries and toolkits will be developed.
Therefore, if you are implementing a language for the Java platform you would want to interact with all of these libraries and toolkits. Problem is that most of them haven't been designed with your language in mind, and they shouldn't be. If
MyLangObject was an injectable interface all you would need to do to be able to integrate with any object from another language would be to just interact with it through the
MyLangObject interface, and the injection mechanism would take care of the rest.
The injection mechanism could even be used with the classes within your language. Instead of having a base class supplying the default implementation of the methods of
MyLangObject you could let the injection method return the default implementation for your methods. Or why not use interface injection to support function invocation with different argument counts. Each function in your language would implement a set of
call methods, one for each argument count it can be invoked with. Your language would then have a set of injectable
Callable interfaces one for each argument count that any function in your language can be invoked with, each with only one
call method, with the appropriate number of arguments. These interfaces could be generated at runtime if your language supports runtime code generation. The default implementation of the call method in each
Callable interface would of course raise an exception, since the function obviously doesn't support that argument count if it doesn't implement the appropriate method.
Interface injection really does provide a huge set of opportunities.
How could interface injection implement a Meta Object Protocol?
There is a great project initialized by Attila Szegedi of the JVM-languages community to create a common meta object protocol (MOP) for all languages on the JVM. With interface injection this would be a simple task.
- Let all objects in your language (that supports the MOP) implement the (probably not injectable) interface
java.dyn.SupportsMetaObjectProtocol. An interface with only one method:
java.dyn.MetaObjectProtocol getMetaObjectProtocol();This would return the implementation of the
java.dyn.MetaObjectProtocolinterface for your particular language.
java.dyn.MetaObjectProtocolcontains methods for getting method handles for each dynamic language construct that the community have agreed to be a good common construct, such as getters and setters for subscript operations. These method handles would come from the actual implementation of them for your particular language, and would therefore benefit from every imaginable optimization you have cooked up for your language.
- When the main interface of my language is being injected into a class from your language it finds that your class implements
java.dyn.SupportsMetaObjectProtocoland uses that to get the method handles for all dynamic language constructs supported by my language, rebinding them them to the method names used in my language.
And as simple as that interface injection has been used to implement a common ground for all languages on the Java platform with absolutely no overhead.
I'm not saying that this is the way to implement a meta object protocol for the Java platform, I am just suggesting one way to do it, someone a lot smarter than me might come up with a much better implementation.
To sum things up: I can't wait until the JVM supports interface injection.
Opinions expressed by DZone contributors are their own.