[code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to handle null targetType [v2]

Maurizio Cimadamore mcimadamore at openjdk.org
Wed Sep 3 10:03:06 UTC 2025


On Tue, 2 Sep 2025 19:34:40 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move the checks out of coerce
>  - Set bodyType to void when scanning a switch expression

Looks good - I left some minor (optional) stylistic comments

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 720:

> 718:                 pt = targetType;
> 719:                 scan(expression);
> 720:                 return result == null || targetType.hasTag(TypeTag.VOID) ? result : coerce(result, expression.type, targetType);

I'd suggest to format like this:


return (result == null || targetType.hasTag(TypeTag.VOID)) ?
    result : coerce(result, expression.type, targetType);


As sometimes humans have issue parsing long conditionals :-)

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1774:

> 1772:         private Body.Builder visitCaseBody(JCTree tree, JCTree.JCCase c, FunctionType caseBodyType) {
> 1773:             Body.Builder body = null;
> 1774:             Type yieldType = tree.type != null ? adaptBottom(tree.type) : syms.voidType;

In general, javac uses `Type.noType` when no target exists. But I understand that here you also want to deal with cases where the target is `void` (because the target is automatically derived from some method return type). We can keep it as is, or we can turn void targets into `noType` and then have `toValue` ignore `noType` (instead of ignoring `void`). Your choice.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/536#pullrequestreview-3179901532
PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2318445353
PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2318451964


More information about the babylon-dev mailing list