Bytecode transformation investigation

[Dan Heidinga]

Thanks for the reply Remi.

> isHidden() returning false is a compatibility issue because i've seen it used has an equivalent of isALambda() (like isAnonymous() was used before isHidden()), GraalVM emulates isHidden() for this reason.

I see two parts to the handling of isHidden.  The first is whether the
*behaviour change* is a *compatibility issue* or an *implementation
detail*.  The fact that classes generated by the LMF happen to be
hidden classes today seems like an implementation detail (especially
given there is no compiler specification that outlines how language
features need to be compiled to classfiles).  How far do we want to
commit to implementation details being compatibility constraints?  I
would posit the platform is moving away from treating implementation
details in this way though there will be cases where they should be
constraints.

The second part is why is an "isALambda()" query useful?  Can you
expand on why it matters whether the instance in hand was created by
explicitly implementing the interface or by the LMF?

>
> For me, instead of trying to emulate those differences, i think it's easier here to provide a method Class.isLambdaProxy() and adds an empty classfile attribute LambdaProxy in the VM spec so both the lambda proxy generated using invokedynamic or pre-generated will mostly behave the same way.
>

That's a potential solution (though a costly one in terms of extra VM
& spec efforts) but can at best be a suggestion as other class
generation tools could easily add the attribute to any class.  I think
we need to understand which implementation details should be treated
as constraints and why this "isALambda" use case is important to
preserve before we spec the solution.

> I'm afraid that Leyden will be exactly that, see how people are using a dynamic thingy, see how it can be emulated it at generation time, provide a way for library developers to see them the same way by bridging the gap between the two and also try to convince library developers that relying too much on implementation details is not a good idea.
>

We agree on educating users not to rely on implementation details.
And that there's going to be a number of implementation details that
we trip over in doing bytecode transformation.  Ideally, we end up
with a consistent approach to decide which ones should be treated as
constraints and which shouldn't.

--Dan

> >
> > --Dan
> >
> > [0] https://github.com/DanHeidinga/jdk-sandbox/pull/1/files (prototype code)
> > [1]
> > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Class.html#isHidden()
> > [2] ex.mod.Example$$Lambda$23/0x0000000800c019f0
> > [3] ex.mod.Example$$Lambda$4
>
> Rémi
>