On Tue, 6 Jan 2026 19:58:10 GMT, Vicente Romero <[email protected]> wrote:
>> Definition and use of a new null checking API
>
> Vicente Romero has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains nine additional
> commits since the last revision:
>
> - Merge branch 'bworld' into JDK-8374149
> - adding a flag
> - additional changes
> - minor changes
> - additional changes to Checks
> - Merge branch 'bworld' into JDK-8374149
> - additional changes
> - Merge branch 'bworld' into JDK-8374149
> - 8374149: [bworld] Define and use new null checking API
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 3506:
> 3504: /** Make an attributed null check tree.
> 3505: */
> 3506: public JCExpression makeNullCheck(JCExpression arg, boolean
> nullRestricted) {
Note -- as we evolve the code more, it would be great if we could get rid of
AST generation inside Attr (currently, we add null check AST nodes as part of
attribution -- which then confuses IDEs who do not expect such changes while
analyzing code).
src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 145:
> 143: allowValueClasses =
> (!preview.isPreview(Source.Feature.VALUE_CLASSES) || preview.isEnabled()) &&
> 144: Source.Feature.VALUE_CLASSES.allowedInSource(source);
> 145: String opt = Options.instance(context).get("useRuntimeChecks");
In principle this could be simplified to:
hasRuntimeChecks = target.hasRuntimeChecks() &&
options.getBoolean("useRuntimeChecks", true);
Right? E.g. emitting an error for the case where `useRuntimeChecks` is set, but
the target is not compatible doesn't seem super important? (Also, how is this
hidden flag used? Do we really need it?)
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1859#discussion_r2668223977
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1859#discussion_r2668220430
