[code-reflection] Integrated: Regularize support for Java types/references

[Maurizio Cimadamore]

On Wed, 21 May 2025 10:00:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR regularizes the support for Java types in the code model. There are two competing constraints to balance: on the one hand, the Java types should be readable from humans when inspecting the textual form of code model; on the other hand, we don't want to bake in Java-specific type parsing in the core code model API.
> 
> Unfortunately, the current implementation scores poorly on both aspects, as (a) textual Java types can become very hard to read (e.g. `.<.<NewTest, NewTest$B>, NewTest$B$C>`), and (b) the parsing logic (defined in `DescParser`) contains several ad-hoc extensions that are only there to support Java types.
> 
> To address this, this PR introduces two different kinds of externalized type forms: *inflated* type forms and *flattened* type forms. An inflated type form closely follow the structure of the `JavaType` or `JavaRef` it models. For instance, the Java type `Foo<? extends Bar>` is modelled as follows:
> 
> 
> java.type.class(Foo, java.type.primitive(void),
>                   java.type.wildcard(EXTENDS,
>                                      java.type.class(Bar, java.type.primitive(void))))
> 
> 
> Inflated type forms can be *flattened* (using `JavaTypeUtils::flatten`), to derive a form that is more suitable for humans. For instance, the above inflated form is flattened as follows:
> 
> 
> java.type:"Foo<? extends Bar>"
> 
> Conversely,  flattened type forms can be *inflated* back (using `JavaTypeUtils::inflate`) to their original inflated form.
> 
> This distinction between inflated and flattened forms allow us to massively simplify `DescParser` -- which no longer has to worries about the syntactic vagaries of Java types. All that complexity is now pushed onto the flattened type forms support. The goal is to progressively make flattened Java type forms an "implementation detail" (more on that below).
> 
> To accommodate flattened and inflated type forms, two changes are needed:
> * in `OpWriter` we need to flatten an inflated type form (if possible) before writing it out as a string (this allows for the textual form of a code model to be more readable)
> * in `OpParser` we need to inflate a flattened type form (if possible) before handing the type form back to the rest of the parsing machinery (which will e.g. invoke the type factory on such inflated type form)
> 
> All Java types and references now follow this pattern:
> 1. the `externalize` method returns an inflated type form
> 2. the `toString` method returns a readable string (the one associated with the corresponding flat type ...

This pull request has now been integrated.

Changeset: 4278b5b4
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4278b5b437334a93cb266bee43c9c922e8fb2611
Stats:     7952 lines in 83 files changed: 846 ins; 452 del; 6654 mod

Regularize support for Java types/references

Reviewed-by: psandoz

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

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