[code-reflection] Integrated: Cleanup and consolidate `ReflectMethods`

[Maurizio Cimadamore]

On Fri, 27 Jun 2025 12:04:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR applies some minor cleanups to `ReflectMethods` and its companion classes.
> 
> * A symbol was moved from `CodeReflectionSymbols` to `Symtab` as it was a method in java.base (MH::lookup)
> * `CodeModelToAST` was merged with `ReflectMethods` (and renamed to `CodeModelTranslator`)
> * To facilitate the above, all the conversion from model types to javac types (and back) is centralized in `ReflectMethods`
> * `ReflectMethod.BodyScanner` is now a regular scanner -- the filtering logic is not needed since all the various relevant trees are supported
> * removed static methods to create javac diagnostics -- we now use the standard methods generated during the build (but this needed to add a qualified export of such generated classes to `jdk.incubator.code`)
> 
> There are several `@@@` comments in the code -- for now I left them in place.
> 
> I believe there are three main areas for subsequent cleanup and/or consolidation:
> 
> ##### Quotable vs. Quoted
> 
> The experiments with lambda to `Quoted` conversions were a first stab on how we might want to support code models in lambdas. This requires ad-hoc type system support (in `Attr`), and `ReflectMethods` does not support method references with this strategy. We should consider whether to keep this, given that we seem to have given `Quotable` a more prominent role in the API (and the language support for `Quotable` is much more in sync with what we do for e.g. serialziable lambdas).
> 
> ##### OpBuilder vs. Text
> 
> `ReflectMethods` still supports two code generation strategies. This doesn't add a lot of additional code, but I wonder if we really need this.
> 
> ##### Inner class support
> 
> The support for member inner classes and local/anonymous inner classes is a bit spotty. The generated model will emit correct code when e.g. creating an inner class -- that is, the model will correctly pass the enclosing this and captured values (where needed).
> 
> But, when translating e.g. a method in an inner class, references to enclosing this, or captured values will not be treated specially -- e.g. `ReflectMethods` will assume such elements to be "in scope". In other words, I have very little confidence that, e.g. we can take a code model corresponding to a method inside an inner class and e.g. generate bytecode for it.
> 
> I wonder if it would be better, for the time being, to just skip reflectable methods/constructors/lambdas defined inside a non-static inner class (so as to provide a cleaner boundary between what we support and what we don't support).
> 
> #...

This pull request has now been integrated.

Changeset: cc00bdcb
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/cc00bdcb215d74a326d2e74d517196b745ccb9a1
Stats:     811 lines in 4 files changed: 288 ins; 484 del; 39 mod

Cleanup and consolidate `ReflectMethods`

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/babylon/pull/468