[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