On Fri, Jun 14, 2019 at 2:45 AM Tim Boudreau <niftin...@gmail.com> wrote:
> 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. > Of course, the changes are as compatible as possible. But, as the Java language evolves, the model evolves as well, correct? Most processors can (hopefully) handle most of the changes, but, as the processor can do whatever it likes, it is difficult to say that all processors are fine. > > 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. > Not necessarily - if you are sure the processor can handle the new models, simply return SourceVersion.latest() from Processor.getSupportedSourceVersion(). > 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. > The model does evolve in practice (default interface methods in 8, modules in 9, etc.). Breakages of annotation processors are hopefully rare, but consider for example our ServiceProviderProcessor (which handles the @ServiceProvider annotation). I doubt it works correctly (or even can work correctly) when compiling a named module. But when compiling for the unnamed module, it is fine even for (currently existing) JDK 9+. > > 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 > That sounds nice, but what is the JDK 8-like model for a module-info? Jan > 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 >
