<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Thanks for the good response Remi.<br>
This is part of a larger FAQ, “why are MHs hard to use?”<br>
Part of the answer is “they model bytecode behavior”.<br>
(Perhaps they should have been called BytecodeBehaviorHandles.)</p>
<p dir="auto">Lifting such raw VM-level behaviors up into Java source code is necessary, but it will never be pleasant, at least not until Java has enough capabilities in its syntax and type system to model such beasties without extra layers of object wrapping.</p>
<p dir="auto">That would include fully incorporating exception checking into the generic type system, a hard problem. It would also involve making some way to name a Java method (perhaps as <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo::bar</code> or <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">myFoo::bar</code> or some lambda) but get a MH out of the expression. Also some kinds of varargs processing might be needed to “add suger” to varargs-related MH transforms.</p>
<p dir="auto">The amount of Java language engineering necessary for such things is so large it will never be done, if MHs are the only use case. There are far too many important improvements to make. (Thought experiment: Should we drop some part of the pattern matching work in order to make room for method handle exception checks? I thought not.)</p>
<p dir="auto">Perhaps in the future there will come a time when exception checking is tracked and/or <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo::bar</code> syntax is made more generic, and that will benefit MHs, but if it happens it will be for a list of weighty reasons, apart from MHs.</p>
<p dir="auto">For now, MH code has to be written in a low-level style in Java source code. (But it works beautifully at the assembly code level, if you are spinning bytecodes.) For example, Java source methods which exist to process MHs should just declare <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">throws Throwable</code>. Then you catch the non-existent throwables at the boundary.</p>
<p dir="auto">You can make this a little easier on yourself, sometimes, if you write a higher-order helper function that takes a Throwable-throwing lambda and sanitizes it down to the exceptions you expect. Then there’s just one clunky <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">catch</code>, and your low-level Throwable-throwing code goes inside lambda bodies.</p>
<p dir="auto">On 21 May 2023, at 6:47, Remi Forax wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">----- Original Message -----</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">From: "-" <liangchenblue@gmail.com>
<br>
To: "core-libs-dev" <core-libs-dev@openjdk.org>
<br>
Sent: Sunday, May 21, 2023 6:52:44 AM
<br>
Subject: Exposing checked exceptions that a MethodHandle can throw</p>
</blockquote><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">Hello,
<br>
I am eliciting a discussion on the feasibility of tracking checked
<br>
exceptions thrown by a MethodHandle. It is already requested in
<br>
<a href="https://bugs.openjdk.org/browse/JDK-8268116" style="color: #999999;">https://bugs.openjdk.org/browse/JDK-8268116</a> as it appears useful in
<br>
the development of Foreign Function Interface API.</p>
</blockquote><p dir="auto">At the bytecode level, checked exceptions are stored in an attribute associated to a method.
<br>
<a href="https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.5" style="color: #777777;">https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.5</a></p>
<p dir="auto">If you have a direct MethodHandle, you can already get the checked exceptions using Lookup.revealDirect() + MethodHandleInfo.reflectAs().</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">Currently, explicit MethodHandle usages are hampered by the catch
<br>
block as the invoke methods are declared to throw any Throwable. Could
<br>
it be possible that we specify the types of possible exceptions at
<br>
MethodHandle invocation, so that:
<br>
1. Javac accepts code that just call the handle without ugly try-catch block
<br>
2. If the exceptions anticipated at invocation site are incompatible
<br>
with (i.e. more specific than) those declared by the invoked handle,
<br>
it can throw an exception like the existing `WrongMethodTypeException`
<br>
eagerly.</p>
</blockquote><p dir="auto">The bug you reference seems to be about runtime information, but the paragraph above is about type-checking information.
<br>
The question here is "is the Java type system good enough to track checked exception in a backward compatible way ?"
<br>
Practically, I believe the answer is no, you can not compose function with different type parameters representing exception, there is no varargs of type parameters, there is no default type argument for a type parameter, etc.</p>
<p dir="auto">It's also significant departure of the way the method handle API is created, the idea behind is that each combiner has the semantics of an existing bytecode. But all invoke* bytecodes are oblivious to exception. Said differently, the method handle API represent how the JVM works, not how Java the language works.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">Is such a plan feasible? Tracking of exceptions should be easy from
<br>
Direct MH and the MethodHandles combinators already, while the
<br>
invocation semantics update might be more complex, maybe in the form
<br>
of compiler-inserted stubs before the actual invoke calls. I wish such
<br>
improvements can make MethodHandle more friendly to direct usages in
<br>
code, so users don't need to wrap MH invocations in try-catch blocks
<br>
everywhere.</p>
</blockquote><p dir="auto">see above.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">Chen Liang</p>
</blockquote><br></blockquote></div>
<div class="markdown" style="white-space: normal;">
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Rémi</p>
</blockquote>
</div></div></body>
</html>