On Wed, 11 Mar 2026 19:28:34 GMT, John R Rose <[email protected]> wrote:
>> So indy bootstrap can have `(Object, Object...)` but that's illegal for >> condy. Condy's 1st arg must be declared exactly `MethodHandles.Lookup`. > > That’s because we aspire (some day) to add new signatures for BSMs (maybe > even indy), where the Lookup is absent, and some other rule applies. > > FTR: It could go either way, towards richer or poorer calling sequences. > Poorer — If a lookup and/or name and/or type are missing you just supply one > according to some rule. Richer (what I prefer) — Allow a single argument > which replaces all three required arguments; it handles most of the hardwired > steps in the JVM today — reflectively extracts name, type, and arguments, > handles all exceptions (for each extraction step). The reason I prefer this > is we can then remove the ad hoc rules from the JVMS, and just say, "If a > Lookup/name/type are supplied (the old way), then it as if the following > standard BSM-handler object were used instead." Less complexity in JVMS, > more power to the end user. One bit of new power: The end user can choose > to reflectively query the ConstantDesc for any or all BSM arguments, instead > of today’s policy of forcing a resolution of all arguments before BSM > invocation (with catastrophic failure if there’s an exception on any > argument). > > Anyway, if we do this stuff, there will be just one place to document it in > the JDK. And even today’s rules deserve a JDK javadoc block linked to all > the BSMs. So we are improving today, and leaving room for future improvement > as well. You asked offline "what about `void` returns from BSMs?" Here’s my reply FTR: There’s been no discussion of this corner case, but the overall philosophy of BSMs is, they are invoked dynamically on only `Object` arguments and returns, because the Constant Pool itself is weakly typed. So `void` is not a type that even appears in the dynamic invocation scheme, except that it is one of the types which has an `Object` representation. (All types known to the JVM have such a representation.) Therefore, there’s no reason to pick out `void` for some special treatment; it already has a uniform treatment under the guise of `(Object)null`. Also, here’s a use-case for a condy-that-returns-void: Perhaps there is a one-time side-effecting setup operation that a “nest” of BSMs needs to happen. Well, just by referring to that condy as an input (somewhere) you thread that dependency into any number of other BSM expressions. Not compelling, but it adds some credibility to the story of making everything uniform in `java.lang.invoke`, even `void`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30125#discussion_r2920514777
