[code-reflection] RFR: Break infinite recursion in ReflectMethods::typeToTypeElement

Maurizio Cimadamore mcimadamore at openjdk.org
Fri Jan 16 11:35:39 UTC 2026


On Thu, 15 Jan 2026 19:25:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following piece of code to crash our compilation with `StackOverflowError`:
> 
>  @Reflect
>  <E extends Enum<E>> void crash(Enum<E> e) {}
> 
> 
> This PR breaks the infinite recursion in `ReflectMethods::typeToTypeElement`.

Are there other alternatives?

One thing that came up to me is that we could model recursive bounds such as the one in this PR with this factory:


static TypeVariableType typeVarRef(String name, TypeVariableType.Owner owner, Function<TypeVariableType, JavaType> boundFunc) { ... }


This factory will:
* create a "dummy" type-variable `T`
* pass that `T` to the bound function, which can create any `JavaType` containing `T` -- let's call such type `B`
* when the function is done, set `B` as the real bound in `T` and return `T` (this will use some mutable state in the implementation)

However, there are issues with this approach:
* it doesn't work with _groups_ of mutually dependent type-variables (see above for an example)
* even assuming we could create a `TypeVariable` object for such a recursive definition, how are we then to _serialize_ such object in the code model text?

Another possibility would be to ditch the type-variable bound from `TypeVariable`, and instead record the type-variable's erasure. Since the erasure cannot, by definition, contain any type-variables, such an approach would avoid the need to check for cycles, while still leaving support for `JavaType::erasure` intact.

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

PR Comment: https://git.openjdk.org/babylon/pull/849#issuecomment-3759634358


More information about the babylon-dev mailing list