On Thu, Jun 13, 2019 at 2:22 PM Jan Lahoda <lah...@gmail.com> wrote: > On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <niftin...@gmail.com> wrote: > > I believe I know what problem this is supposed to solve, and I don't think > it is related to what you are describing. The problem is rather this: > imagine someone has written an annotation processor for JDK 8, with the > knowledge of the JDK 8 Java lang model. That's good. Now, in some future > version of Java, the model is enhanced to cover the language features. It > is unclear whether the processor can handle the new model correctly or not. > It may (and it is easily imaginable) pass vacuously, which may mean the > compilation may pass without any errors or warnings, but the processor > didn't do what it was supposed to do (e.g. create a META-INF/services > registration). That is a fairly bad situation, IMO: no warning, but > incorrect output produced. > > In other words, the Processor.getSupportedSourceVersion() returns the > highest model version the processor can safely handle. > > Maybe the exact implementation of this check could be better, but I don't > think we could say it is "useless". >
Oh, I understand the reasoning. But the Java language model is API or it isn't? If javac goes and changes it and breaks a lot of annotation processors, I think enough users of them would scream bloody murder that that change would be unlikely to make it into the JDK. I've written enough annotation processors that I will certainly be one of them. Seriously, what this implies is that, if you are an annotation processor author, you didn't know it but you are married to making a pointless update to your annotation processor with every JDK release until the day you die, or perfectly will look like it's broken to all its users. That's insane. Is there a real world example of this happening? If not, then this is a "but someday, somebody might need this" feature, and we both know those are a bad idea. Here's how supportedSourceVersions() *should* be used by javac: Not as a "this annotation processor may be broken, warn the user" notification, but as a signal to javac *that it needs to expose the model to that annotation processor using the API available to javac in the JDK of that source version.* In other words, this should be a hint to javac about the types the annotation processor expects; and perhaps deprecate / delete compatibility layers for older JDKs on a schedule. Making this the annotation processor author's problem, or worse, the annotation processor user's problem, is the worst possible solution. If the compiler is going to break its API, it should not be other people's problem to deal with it. And it certainly shouldn't be making people jump through hoops to fix warnings that it *might have* when it actually hasn't. So, yeah, I get the reasoning, but it is the wrong solution to a problem that has yet to actually exist, yelling at people to do something because it might. -Tim
