On Fri, 6 Mar 2026 14:19:28 GMT, David Beaumont <[email protected]> wrote:
>> This changed because the compiler is bimodal and *either* takes the >> processor path from "processor-path" *or* it takes it from the service >> provider info (which I don't think is the right approach here). >> However this also is the plugin path. >> >> So if you add `--processor-path` you break the depend plugin, because it >> *used* to use the *classpath*, but now that mechanism is disabled in favour >> of the *processor path*. >> >> Thus it is necessary to also add the depend plugin path to the processor >> path. >> >> This is achieving exactly the same thing as before and is an internal >> detail, and without it, you cannot specify an annotation processor path. >> >> I'm happy to add documentation wherever you feel it necessary/helpful, >> please make suggestion as you see fit. > > I added a couple of lines of docs in JavaCompilation.gmk (please take a look) > but also am now wondering about the naming inconsistency between "CLASSPATH" > and "PROCESSOR_PATH". Do you want me to change it to "PROCESSORPATH" ? I don't have a concern for the name. IMO "CLASSPATH" is a special case for historical reasons, it's just common practice to write it as one word. This variable represents an option where the words are separated. I have a minor concern about modifying the external parameter variable. That is something we try to avoid (though I'm sure there are other instances present if you look closely). It would be better if there was a separate internal variable that was constructed in the macro and then used. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2180#discussion_r2905330945
