RFR: 8372948: Store end positions directly in JCTree [v6]

[Jan Lahoda]

On Mon, 26 Jan 2026 13:04:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/langtools/tools/javac/api/TestJavacTask_Lock.java line 72:
>> 
>>> 70:         fm = comp.getStandardFileManager(null, null, null);
>>> 71:         try {
>>> 72:             MethodKind first = MethodKind.CALL;
>> 
>> I think it would be good to preserve the behavior (i.e. prevent `parse` followed by `call` or `parse`). Otherwise, I am not sure if there may not be some a bit surprising effects (like calling `parse`, then `analyze` then `parse` again and `analyze` again might lead to some weird errors). If there would be a reason to relax this restriction, it would probably merit its own PR and own investigation of effects.
>
> Thanks, I had meant to look into this more if there was interest in the overall change, so this seems like a good time to revisit it.
> 
> Currently it works because a repeated call to `PARSE`, or calling `CALL` after `PARSE`, will fail with `IllegalStateException: endPosTable already set`. I reverted the workaround in the test and added an explicit check to replace the dependency on the `EndPosTable`:
> 
> 
> +        if (used.get())
> +            throw new IllegalStateException();
> 
> 
> I also noticed that there's no validation to disallow repeated calls to `ANALZYE`, I wonder if there should be?

Thanks! Calling `analyze` multiple time should not break anything, I think - that don't necessarily mean it is a good idea, but I suspect calling `parse` multiple times could lead to weird outcomes, so that one was more important.

I think adhering to the current behavior for now is good - we can thing and decide separately whether we want to make `parse` safe to call multiple times, restrict `analyze`, or let things be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2732160099