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
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
