----- Original Message ----- > From: "John R Rose" <[email protected]> > To: "compiler-dev" <[email protected]>, "core-libs-dev" > <[email protected]> > Sent: Wednesday, March 11, 2026 8:33:33 PM > Subject: Re: RFR: 8379446: Annotation to mark intended bootstrap method > declarations
> 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`. You can use that as a cheap way to compute code coverage :) Especially if you combine it with a StackWalker to find the bci of the caller of the BSM. regards, Rémi > > ------------- > > PR Review Comment: > https://git.openjdk.org/jdk/pull/30125#discussion_r2920514777
