[code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
Maurizio Cimadamore
mcimadamore at openjdk.org
Wed Sep 10 11:28:53 UTC 2025
On Tue, 9 Sep 2025 01:47:10 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:
>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>
> Apply suggestion
The change in this PR looks good. But, I'd like to remind ourselves that we have probably several issues when it comes to dealing with lambda expressions. There are a bunch of reasons where javac wants to use the `altMetafactory` instead of the regular one:
1. when the target of the lambda has one or more "empty markers" -- e.g. `(Runnable & Cloneable) () -> ...`
2. when the target of the lambda is serializable -- e.g. `(Runnable & Serializable) () -> ...
3. when the metafactory needs to also implement one or more "bridge" methods
An example of (3) is as follows:
interface A<X> {
void m(X x);
}
interface B<X extends Number> {
void m(X x);
}
interface C extends A<Integer>, B<Integer> { }
C c = (i) -> System.out.println(i);
In the above example javac will ask the `altMetafactory` to generate an additional bridge implementation for the `(Ljava/lang/Object;)V` signature.
While there's things we can do to detect (1) and (2), I think the kind of analysis required for (3) is rather difficult, and compile-dependent:
https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L927
And I'm quite skeptical we can reproduce this at runtime (as the runtime capabilities to detect overriding based on source-level types are rather limited).
So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.
-------------
PR Comment: https://git.openjdk.org/babylon/pull/545#issuecomment-3274529189
More information about the babylon-dev
mailing list