[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