[code-reflection] RFR: Refactor code for computing denotable projection of types

Paul Sandoz psandoz at openjdk.org
Fri Nov 28 20:01:19 UTC 2025


On Tue, 25 Nov 2025 19:07:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The code reflection support needs a way to compute the closest fully denotable supertype of the type of an expression. To do this we build on [type projections](https://docs.oracle.com/javase/specs/jls/se25/html/jls-4.html#jls-4.10.5), but this doesn't work fully, because type projectios still allow intersection types in, and the `JavaType` API (or the `j.l.r.Type` API) doesn't have a way to model these.
> 
> For this reason, we had to tweak the compiler code in `Types` to accept an extra parameter to tell the projection to also discard intersection/union types. While this works, this creates a lot of noise in the compiler codebase, so I've been looking for a lower-maintenance alternative.
> 
> The basic idea behind this PR is to apply a normalization pass _before_ we compute a vanilla type projection. This normalization pass essentially replaces any intersection type with a fresh type variable whose bound is the first bound of the intersection.
> 
> As an example, consider the type: `Foo<A & B & C>`:
> 
> 1. we first transform this type into `Foo<#1>` where `#1` is a fresh type-variable with upper bound `A`
> 2. we then add `#1` to the list of type variables to be "projected"
> 3. we then compute the upward projectin of `Foo<#1>`, and obtain `Foo<? extends A>`.
> 
> This process is sound because (a) replacing `A & B & C` with a fresh type variable with bound `A & B & C` is sound, and because (b) upward projection will always map such type variables into some kind of wildcard (so dropping some bounds from the intersection doesn't make any difference) -- unless the type is a toplevel type, in which case, again dropping a bound doesn't make any difference.

Very nice, this seems more rigorous and explainable, and we don't impact the visiting of types in the compiler nor extend the definition of upward projection. (There are ways we can improve the performance later if an issue.)

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/707#pullrequestreview-3519846939


More information about the babylon-dev mailing list