RFR: JDK-8267690: Revisit (Doc)Tree search implemented by throwing an exception

Pavel Rappo prappo at openjdk.java.net
Mon Apr 25 15:59:50 UTC 2022

On Fri, 22 Apr 2022 19:10:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderately simple cleanup change, to eliminate using an exception to terminate scanning a `Tree` or `DocTree` in `(Doc)TreePath.getPath`.
> The change is to set a field with the intended result, and once that field is set, do "best-effort" to eliminate any addition scanning.
> It is easy enough to stop scanning items in a list, but it is not practical to totally stop scanning the subsequent sibling nodes, but we can substantially reduce the cost of scanning those nodes, and can definitely avoid scanning any children of those nodes.

You are not changing `(Doc)TreeScanner` API, but fixing this pair of internal `(Doc)TreePathScanner` subclasses; okay.

I think that your suggestion goes the extra mile as opposed to a more succinct suggestion by Jan [^1]. In particular, you avoid creating unnecessary `(Doc)TreePath` objects and calling `reduce`.

Could you have a look at other cases where we use `(Doc)TreeScanner` for search? For example:

  * com.sun.tools.javac.tree.TreeInfo#pathFor
  * com.sun.tools.javac.tree.TreeInfo#containsTypeAnnotation
  * jdk.jshell.ExpressionToTypeInfo#findExpressionPath
Maybe there's more. Is it possible to use your code there too? It would be good!

[^1]: https://bugs.openjdk.java.net/browse/JDK-8267690?focusedCommentId=14448893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14448893


PR: https://git.openjdk.java.net/jdk/pull/8369

More information about the compiler-dev mailing list