Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for http://blogs.sun.com/jrose/entry/method_handles_in_the_vm (forthcoming) One pain point in dynamic language implementation is calling dynamically linked code under a variety of names, containing classes, and signatures. The JVM's static linking and typing rules, which usually serve to enforce system integrity, get in the way with dynamic languages. A method handle can be formed on any method, with suitable access check performed at the point of handle creation (not call). The handle will allow its target to be accessed from any caller which obtains the handle. It is a low-level function pointer. Because method handles are low-level monomorphic (singly-typed) objects, they behave as if they possess instance-specific behavior. They also exhibit descriptor polymorphism, in that different instances can respond to calls with different argument and return signatures. Neither of these features are available in the current JVM, except by simulating with combinatorially complex system of signature interfaces, or inefficient reflection. The interesting operations on method handles are about the same as with any system of functional types: - creating one from an isolated method - creating one from a bit of code, with associated data values - invoking one on some arguments - creating an adapter around one - asking one for its argument and return types
|