[code-reflection] RFR: JavaRef extends TypeElement

[Paul Sandoz]

On Wed, 30 Apr 2025 09:02:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/jdk/java/lang/reflect/code/type/TestReferences.java line 52:
>> 
>>> 50:                 {"java.io.PrintStream::println(java.lang.String)void", "java.io.PrintStream", "println"},
>>> 51:                 {"MethodReferenceTest$A::m(java.lang.Object)java.lang.Object", "MethodReferenceTest$A", "m"},
>>> 52:                 {"R<#T<R, java.lang.Number>>::n()#T<R, java.lang.Number>", "R<#T<R, java.lang.Number>>", "n"}
>> 
>> Parsing of MethodRef should eventually disappear, right? E.g. one thing is parsing the externalized method ref -- (which can be done in a principled way) but parsing a MethodRef using a slightly different externalized string (like in this test) seems confusing. (Same for all JavaRefs, really)
>
> Ok, this is covered by your `We still rely on the bespoke string form for java refs, which is used as the value of an externalized attribute` comment. And also explains why there are only so few changes in tests (I was expecting anything using invoke, or field load to need a refresh :-) ).

Indeed. The parsing of java refs should eventually become a private thing of the `OpParser`. So `OpWriter` can use `JavaRef.toString` i.e., an identical approach proposed for `TypeElement`.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/416#discussion_r2069213667