On Mon, 26 Jan 2026 13:04:42 GMT, Liam Miller-Cushon <[email protected]> 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
