On Dec 2, 2020, at 2:53 AM, Remi Forax wrote:
>
> There is one case where i dynamically patch a method descriptor so I can
> select how many arguments will be sent to a closure,
> i.e. in the bytecode i put all arguments on the stack but because i've
> patched the callee descriptor, only some o
> On Dec 2, 2020, at 3:53 AM, Remi Forax wrote:
>
> Using a condy that returns a String instead of a method descriptor in the
> bytecode ?
> I'm currently trying to remove the uses of Unsafe.defineAnonymousClass to use
> Lookup.defineHiddenClass instead.
> There is one case where i dynamically
All quiet on the list the last couple of weeks. Let's cancel today's meeting.
We'll also want to cancel the meeting at the end of the month. So the upcoming
schedule is:
December 16
January 13
January 27
Remi has posted a few miscellaneous questions this morning, which I think are
best addresse
Hi all,
currently an inline record like this
public @__inline__ record IntBox(int value) {
}
generates two classes, IntBox and IntBox$ref, IntBox being the record itself
and IntBox$ref being the abstract class representing the nullable version of an
inline that inherits from java.lang.Record
Most of the error message form the error that can be thrown by classes of
java.lang.invoke are using Class.getSimpleName() which makes debugging hidden
classes painful because getSimpleName() scrubs the hexadecimal number part of a
hidden class name.
It also seems that the VM has a zealot stanc
Using a condy that returns a String instead of a method descriptor in the
bytecode ?
I'm currently trying to remove the uses of Unsafe.defineAnonymousClass to use
Lookup.defineHiddenClass instead.
There is one case where i dynamically patch a method descriptor so I can select
how many arguments
