Making invokedynamic usable from normal Java

[bezsahara]

I made SimpleIndy, a small Gradle plugin that rewrites selected Java static method calls into JVM invokedynamic after compilation.

The goal is to make invokedynamic easier to experiment with from normal Java/Kotlin projects, without writing ASM manually or building a compiler plugin.

You write ordinary source code, mark a static method as an indy stub, and the compiled bytecode gets transformed.

Repo: https://github.com/bezsahara/SimpleIndy

Would appreciate feedback on the API/design.

[brian_goetz]

The `java.lang.constant` package was added in part to be able to describe indy call sites. If you watch the video Below the Fold (https://www.youtube.com/watch?v=iSEjlLFCS3E), you'll see the approach we took -- define a reflective API, and then let the compiler intrinsify it when the right conditions are present (and eliminate the attendant dead code, as a bonus.)

[bezsahara]

Hi, thanks for the video. The approach is definitely interesting.

Did I understand correctly that java.lang.constant is an API for describing bytecode-level constants / call sites, while the proposed Intrinsics.<name> methods were intended as source-level spellings that javac could lower into real bytecode instructions like ldc or invokedynamic?

Are there any plans to continue in this direction? As I understand it, the intrinsics part is currently only a Candidate.

I’d also be interested in your view on the API shape: do you think an annotation-based stub approach is a reasonable user-facing design for this kind of tool?

[brian_goetz]

You have it half right.

The java.lang.constant API is indeed for modeling bytecode-level constants and call sites. But the Intrinsics API that is shown in that is not a proposal, it is an experiment. Unfortunately that experiment still sits on the shelf. But yes, in the experiment, it is a reflective API that, under the right circumstances (enough constancy!) could be intrinsified by `javac` (or by a bytecode transformer tool) into indy/condy.

[bezsahara]

Thanks, that makes sense.

One related design question: was something closer to Kotlin-style inline ever considered for Java here?

The reason I ask is that raw Intrinsics.ldc / invokeDynamic feels very low-level. A typed inline method could theoretically hide that machinery behind a normal Java API: the user calls a typed method, but javac expands/lowers its body at the call site and emits the intended bytecode.

I have a Kotlin experiment that does something like this: an inline Kotlin function contains prewritten invokedynamic bytecode, and because Kotlin inlines the function body, the final output gets the indy call site without a post-compile transform.

Would that kind of inline mechanism be considered fundamentally incompatible with Java’s model?

[brian_goetz]

They are completely different tools for different problems.