On Sep 17, 2015, at 10:10 AM, Michael Haupt <michael.ha...@oracle.com> wrote:
>
> ummm ... this seems to imply I can remove the findSuperConstructor() proposal
> from the Indy JEP. Incidentally, it's on my list for this week - and less
> work is always good. ;-) Even if, in this case, it leads to disappointment. I
> agree with you in that opening up the MH API like this will introduce several
> trapdoors and additional complication.
>
> Please let me know ...
Hi Michael. See previous message. It looks like (in most cases, mostly) the
burden can be put back on the bytecode generators, like Groovy.
In a couple of cases we might want to add API for these use cases:
1. The workarounds are so complex and error-prone that a convenience function
is needed. (As with PICs, etc., requires a matured notion of what the
convenience should be.)
2. We might still need some sort of multi-way super.<init> call, but I think
there are bytecode-level workarounds for this also, that verify today. (The
multi-way super comes is visible in the "no can do!" comment of my POC code.)
— John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
