On Thu, 6 Aug 2026 17:49:46 GMT, Chen Liang <[email protected]> wrote:
>> This plugin runs during parsing when the type has not yet been resolved and
>> set. I am not fully aware of all the reasons that we decided to do this
>> during parsing. But it seems like `javac` consumes the information we are
>> modifying before it does its analysis which figures out the type and
>> populates the type field.
>>
>> I think if we want to be able to do this later we would have to either
>> change javac, or mimic what javac does here and not only fix-up what we
>> already do, but also repair any derived properties.
>>
>> I think doing it like this is a pragmatic albite hacky solution.
>>
>> It would be nice if there was a more elegant solution here, but that is not
>> a solution I can currently see. (But I am very much a newcomer to the javac
>> code and tooling)
>
> What about handling at the ENTER stage? I don't think tweaking
> `tree.mods.flags` must happen right after initial parsing.
After digging deeper into what javac does. We both consume `tree.mods.flags`
and produce `annotationType.type` in ENTER. So we would need to plugin at the
back edge of ENTER.
I may be that the `tree.mods.flags` consumption in `Enter::visitClassDef` can
handle us changing state efter ENTER. I think what we miss is the guard against
implicit addition of `IDENTITY_TYPE` in `Check::checkFlags`.
I think someone with greater javac knowledge has to convince me that it would
be fine to do this after we have read out the state.
But currently there is no point where we can hook in a plugin where it has
`annotationType.type` and the state we want to modify has not already been read.
javac enter order of operations:
tree.mods.flags consumed
↓
imports resolved
↓
annotationType.type populated
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32214#discussion_r3734898616
