PROPOSAL: language support for JSR 292 (original) (raw)

Josh Suereth joshua.suereth at gmail.com
Sun Mar 29 07:55:38 PDT 2009


John,

I'm curious as to why you chose to not allow catching checked exception from Dynamic method calls. I think it would be nice to make a dynamic method call and try to catch, e.g. JdbcExceptions vs. MethodMissing exceptions. I haven't lookied into MethodHandles + InvokeDynamic in depth yet, so if they are wrapping checked exceptions with unchecked exceptions, then ignore this comment.

I really like this proposal and am looking forward to seeing it make it into the Java Language.

On Sun, Mar 29, 2009 at 2:53 AM, John Rose <John.Rose at sun.com> wrote:

Hello, colleagues. Here is a proposal which is linked to JSR 292 (invokedynamic).

http://wikis.sun.com/display/mlvm/ProjectCoinProposal http://blogs.sun.com/jrose/entry/jsr292supportinjavac Here's the teaser (from my blog): In order to work with dynamic types, method handles, and invokedynamic I have made some provisional changes to javac as part of the Da Vinci Machine Project. The mlvm wiki has a full description for Project COIN. It is most desirable, of course, to program invokedynamic call sites as Java expressions, not just ASM code, and that's what those langtools patches are for. The essential features are four: • The type java.dyn.Dynamic will accept any method call and turn it into an invokedynamic instruction, and the full range of such instructions can be spelled from Java code. • The type java.dyn.MethodHandle will accept any argument and return types for a call to the method named invoke, which means that Java code can spell the full range of method handle invocations. • The full range of bytecode names acceptable to the JVM can be spelled from Java code, using an exotic identifier quoting syntax. • The type java.dyn.Dynamic serves as a bare reference type: Anything implicitly converts to it, and it can be cast to anything, but it is not a subtype of java.lang.Object. Its methods, of course, are those from point #1, so it is handy for forming invokedynamic calls. The rationale is pretty simple: If we put some minimal support into Java for defining and using names in other languages, then Java can be used as a system programming language for implementing them. Otherwise, the system programming language will be assembled bytecode. (I like to visit ASM, but don't want to live there.) Do check out the wiki page; it has the full Project COIN proposal format. Best wishes, -- John Rose (Da Vinci Machine Project)



More information about the coin-dev mailing list