Thanks Peter - I'd like that too.
Another benefit is that it would (presumably) force IDEs to support the
syntax so that you could this reference to, in your example, someMethod().
We had a problem in our large-ish codebase with methods that looked unused
to the IDE (and hence the casual reader), but were in fact peeled off for
use as MHs. We solved the is-it-used-or-not problem by switching to a
helper lookup class which works off a @MethodHandle annotation. It's still
not very navigable though, because the lookup referencing ultimately goes
by method name strings and so isn't visible to the IDE.
George
On Mon, Mar 9, 2015 at 1:38 PM, Peter Levart <peter.lev...@gmail.com> wrote:
> On 02/26/2015 01:02 AM, Charles Oliver Nutter wrote:
>
>> After talking with folks at the Jfokus VM Summit, it seems like
>> there's a number of nice-to-have and a few need-to-have features we'd
>> like to see get into java.lang.invoke. Vladimir suggested I start a
>> thread on these features.
>>
>> A few from me:
>>
>> * A loop handle :-)
>>
>> Given a body and a test, run the body until the test is false. I'm
>> guessing there's a good reason we don't have this already.
>>
>> * try/finally as a core atom of MethodHandles API.
>>
>> Libraries like invokebinder provide a shortcut API To generating the
>> large tree of handles needed for try/finally, but the JVM may not be
>> able to optimize that tree as well as a purpose-built adapter.
>>
>> * Argument grouping operations in the middle of the argument list.
>>
>> JRuby has many signatures that vararg somewhere other than the end of
>> the argument list, and the juggling required to do that logic in
>> handles is complex: shift to-be-boxed args to end, box them, shift box
>> back.
>>
>> Another point about these more complicated forms: they're ESPECIALLY
>> slow early in execution, before LFs have been compiled to bytecode.
>>
>> * Implementation-specific inspection API.
>>
>> I know there are different ways to express a MH tree on different JVMs
>> (e.g. J9) but it would still be a big help for me if there were a good
>> way to get some debug-time structural information about a handle I'm
>> using. Hidden API would be ok if it's not too hidden :-)
>>
>> That's off the top of my head. Others?
>>
>> - Charlie
>>
>
> Hi,
>
> What would be nice to have is support for constant direct method handles
> and invokedynamic in Java language. We already have a syntax (thanks to
> lambdas) and target typing. What I'm asking for is for the following...
>
> constant direct method handles:
>
> class C {
> int someMethod(String s);
> }
>
> ...
>
> MethodHandle mh = C::someMethod(String);
>
> No pre-bound MHs, no overloaded method resolution. Just plain compilation
> to MH constant load.
>
>
> invokedynamic:
>
> There already was support for this in JSR292 prototype. Why was it removed?
>
>
> If for nothing else, this would simplify writing tests and experiments.
> Currently all we have is bytecode spinning with tools like ASM.
>
>
> Regards, Peter
>
>
> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
