On Sat, Jun 15, 2019 at 7:26 AM Jan Lahoda <[email protected]> wrote: > On Sat, Jun 15, 2019 at 12:39 PM Tim Boudreau <[email protected]> wrote: > > > > > Very simply, and exactly as I described: It doesn't exist in the API > > for > > > > annotations in JDK 8, so the annotation processor should never be > > passed > > > > any reference to it. It doesn't exist. > > > > > > > > > > It is unclear to me how this really helps processors like the > > > ServiceProviderProcessor do the right thing (whatever that is) when > > > compiling a named module? > > > > > > > If you accept my second suggestion (allow version- or language-feature- > > specific processors), then it allows you to have separate module-aware > > (whatever it does) and non-module-aware implementations. Most annotation > > processors probably won't need that, but it solves the corner case for > one > > that does - instead of screaming at users that their Java version is too > > new, the compiler can just pick the appropriate implementation. > > > > Well - the APs can do that, if they wish, right? (And, frankly, it is not > that difficult - it is quite possibly easier than maintain several copies > of the AP, just to have one for "old" JDKs and one for "new" JDKs.) >
Yes, but they cannot eliminate the warning. And the whole point is, if the annotation processor is not broken: - the annotation processor author should not have to "fix" it - users should not be scared by warnings when nothing is wrong > > > > For that matter: You're the Java compiler (yes, you, Honza, are > personally > > the Java compiler! I imagine you have days where you feel like that :-)). > > > > Well, even if I accepted that I am the Java compiler (which, frankly, I am > not really), what you are talking here is JSR 269 *design*. And I am surely > not that. You are redesigning how APs work here, and, frankly, there are > different venues to do that than this list! I might be the one implementing > the design, but not the one doing the redesign. > True enough. -Tim
