[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