I wouldn't expect JSpecify to understand the semantics of the code that is passed as a filter, even e.g. filter(e -> e != null). A fix would be using flatMap or mapMulti where type inference can do a better job. Otherwise you could add a map with requireNonNull after filtering.

It can be used that way (from my basic understanding of lazy val), but it's more powerful semantically and especially performance-wise.

And use the well-known https: label combined with a comment to make sure readers will never look at your code without syntax highlighting again

That sounds interesting and promising. Thanks!

What does "a Java interpreter" mean? Espresso, or something new? Is the plan to make it work transparently (i.e. native code can just load a new class as if it is running in a "normal" JVM) or will it need customization?

As far as I know it's licensing concerns. The first two points at chriswhocodes.com/hsdis/ sound similar to that too.

This seems to be some kind of copy-paste mistake?

To me, the biggest downside is still the fact that it isn't part of the OpenJDK (besides e.g. nixpkgs only providing the community edition).

Which language are you using?

To add insult to injury: the IntelliJ Plugin Verifier mentions usages that do not appear in source code. I guess that's a Kotlin-specific problem.

As I'm releasing from GitHub automatically, that also means that the version is already published there. I'll need to publish a new version that then is released on both GitHub and the marketplace (hopefully), again. I don't think that's in anyone's interest.