Interface injection

[John Rose]

On Jul 14, 2008, at 10:07 AM, Tobias Ivarsson wrote:

> I've done a fair amount of thinking about interface injection:  
> http://journal.thobe.org/2008/07/my-jvm-whishlist-pt-1-interface.html
> I would really like to see this happening. Is anybody working on  
> it? What would it take to bring interface injection to hotspot? Is  
> there any way I can help?
>
> best wishes,
> Tobias Ivarsson

I'm excited that you are excited!  I have dumped a few more notes  
online, and you are welcome to do so also:
   http://wikis.sun.com/display/mlvm/InterfaceInjection

(Make a wiki ID and send it to me and I will give you edit access.   
Same offer goes to any mlvm contributor.)

I'm working hard on method handles this month, so I don't have much  
time for anything else.  But I (and people on this mlvm-dev list)  
would be interested to talk more about concrete implementation details.

The dense answer to your question is that it would take the following  
items to bring interface injection to HotSpot:
- method handles as an enabling technology (to simplify certain  
details of implementation and specification)
- a proof of concept coded (as inti.patch) in the Da Vinci Machine  
project
- a clean, clear, precise specification, independent of HotSpot
- a few exciting uses of it (i.e., some wins to motivate adoption)
- eventually, incorporation in JSR 292 or a successor JSR

You raised the question on your blog about the interactions with  
reflection, esp. Class.getInterfaces.  The question of reflection  
always comes up with such extensions.  My answer is usually that it  
is OK to surface the new functionality as new methods in the Core  
Reflection API.  So you might have Class.getInjectedInterfaces, as a  
changing quantity.  You would also have Class.getRejectedInterfaces;  
both sets would never shrink over time.

I had a further thought today about this:  Interface injection must  
integrate with subtyping properly, but perhaps there is a clean way  
to get a separate injection decision for each class in a hierarchy,  
rather than just one for the top.  Of course interface methods need  
to override each other; maybe the injection decision point can  
declare that an injection is _final_ for a particular class (meaning  
every subclass reuses that injection).  But if an injection is not  
final (w.r.t. the class hierarchy is what I mean), the each subclass  
also gets an injection event.  This can be useful as a way to hand  
customized per-class state on classes.

The most obvious use (for dynamic languages) is to associate a  
metaobject with each class encountered by the dynamic language  
runtime, but there are other uses too, such as associating counters  
with classes, etc.  By using interface injection, such appended state  
would be just a method call away.  (This also raises the question of  
an API for getting injected properties from the class itself, even if  
you don't have an instance to invoke on.)

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080716/36c131d0/attachment.html