* 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.

I agree there.  We should put this in.

    MHs.tryFinally(target, cleanup)(*a)
      => { try { return target(*a); } finally { cleanup(*a); } }

(Even here there are non-universalities; what if the cleanup
wants to see the return value and/or the thrown exception?
Should it take those as one or two leading arguments?)
Probably, it's too much. Result-agnostic cleanup logic looks like the cleanest solution from API perspective.

There are catchException and foldArguments/filterReturnValue to combine with. Or am I missing something?

* 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 :-)

Idea of the day:  An ASM-like library for method handles.
Make a MethodHandleReader which can run a visitor over the MH.
The ops of the visitor would be a selection of public MH operations
like filter, collect, spread, lookup, etc.
Also ASM-like, the library would have a MethodHandleWriter
would could be hooked up with the reader to make filters.
Not sure how useful it would be for an API user. I find it hard to recover MH transformation chains from MethodHandle trees, since the representation we use is quite low-level. They end up as trees of BoundMethodHandles and you can guess the intention only by carefully inspecting LambdaForms.

You can try it yourself by turning on -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true and calling MethodHandle.toString() on a method handle of your choice.

Best regards,
Vladimir Ivanov
mlvm-dev mailing list

Reply via email to