PROPOSAL: language support for JSR 292

[Josh Suereth]

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.


- Josh

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/jsr_292_support_in_javac
>
> 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)
>
>