On Fri, Jun 14, 2019 at 1:21 AM Jan Lahoda > > > 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. > > > > Not necessarily - if you are sure the processor can handle the new models, > simply return SourceVersion.latest() from > Processor.getSupportedSourceVersion(). > > 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?
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. i don't think there ought to be any difficulty handling *additions* to the API, and for the most part that takes care of itself, since the annotation processor won't reference classes that didn't exist when it was written. You'd have to filter the set returned by getElementsAnnotatedWith, but that's simple. The only corner case is an annotation processor written against, say, JDK 9 but supporting source level, say, 7. There it might be better to allow an annotation processor which can specify "only run me on JDK 7" and "run me on 9 and up" if you want to use 9-specific stuff. -Tim > > 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 > > > -- http://timboudreau.com
