RFR: 8372948: Store end positions directly in JCTree

Liam Miller-Cushon cushon at openjdk.org
Wed Dec 3 09:47:11 UTC 2025


On Tue, 2 Dec 2025 16:43:43 GMT, Jonathan Gibbons <jjg3 at pobox.com> wrote:

> I'm not sure a shared interface gets you anything significant, since you cannot inherit a shared field that way.

Partly I was thinking the interface could make helpers that set end positions type safe, e.g. for the `storeEnd` method in `JavacParser` if we could write something like:


protected <T extends JCTree & JCTree.HasEndPos> T storeEnd(T tree, int endpos) { ... }


But there are other places that store end positions on a `JCTree` instead of a specific subtype, so that approach only goes so far.

> Instead, you could have a `setEndPos` on `JCTree` that is a no-op on subtypes that do not need it, and which sets a locally declared field on subtypes that do need it.

I think the set of trees that end positions are stored for is: `JCAnnotation`, `JCArrayAccess`, `JCArrayTypeTree`, `JCAssert`, `JCAssign`, `JCBinary`, `JCBindingPattern`, `JCBlock`, `JCBreak`, `JCCase`, `JCClassDecl`, `JCConstantCaseLabel`, `JCContinue`, `JCDefaultCaseLabel`, `JCDoWhileLoop`, `JCExports`, `JCExpressionStatement`, `JCFieldAccess`, `JCIdent`, `JCIf`, `JCImport`, `JCLambda`, `JCLiteral`, `JCMemberReference`, `JCMethodDecl`, `JCMethodInvocation`, `JCModifiers`, `JCModuleDecl`, `JCNewArray`, `JCNewClass`, `JCOpens`, `JCPackageDecl`, `JCParens`, `JCPatternCaseLabel`, `JCPrimitiveTypeTree`, `JCProvides`, `JCRequires`, `JCReturn`, `JCSkip`, `JCSwitch`, `JCThrow`, `JCTypeApply`, `JCTypeParameter`, `JCTypeUnion`, `JCUnary`, `JCUses`, `JCVariableDecl`, `JCWildcard`, `TypeBoundKind`

I got that by instrumenting `SimpleEndPosTable` and building the JDK, it's possible it missed a few.

And then we could add the following snippet to all of those classes:


    private int endpos;

    public int getEndPos() {
        return endpos;
    }

    public void setEndPos(int endpso) {
        this.endpos = endpos;
    }


My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3605955451


More information about the compiler-dev mailing list