[code-reflection] RFR: Conflicting code reflection fields for method overrides
Adam Sotona
asotona at openjdk.org
Fri Jun 28 16:06:37 UTC 2024
On Fri, 28 Jun 2024 15:54:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 374:
>>
>>> 372: }
>>> 373: };
>>> 374: for (var p : method.params) {
>>
>> I'd suggest to call the signature generator on the type obtained from `method.sym.externalType(types)`, as that will take into account any extra synthetic parameter that might be added later by javac (which will end up in the bytecode) - e.g. for inner class constructors.
>
> Could we encode an instance of `MethodRef` in the field name like we do with the invoke operation's descriptor? (I believe there are less restrictions in the names of synthetic fields than ones that can be denoted in source.) That might be easier to manage on the compile time and run time sides.
Technically to create fields `<method name>+<signature>+$op` still looks like a quick workaround.
Can we introduce a custom method attribute or annotation?
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/162#discussion_r1658961597
More information about the babylon-dev
mailing list