On Sat, Jun 15, 2019 at 4:24 AM Tim Boudreau <niftin...@gmail.com> wrote:
> 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. > 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? Or, as an another example, imagine an annotation processor that checks that all classes referred to from a public API (classes, methods and fields) are public API classes as well. It needs to determine what is the API, and (as it is written for JDK 8 originally) it is using a heuristics for that. When compiling a JDK 9+ named module, there is no need for the heuristics, and using the heuristics may lead to either false reports (which is not that bad), but also to a false "acceptance/pass" of the program (i.e. the AP may be silent), which is worse. And hiding the model for modules from the AP is not going to improve this. > 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 > I think this is trying to solve a problem where the AP may crash on seeing a new kind of elements. This still leaves some open questions, but, for me, a more important case is the case where the AP does not fail, but also does not do what it is supposed to do silently. It is hard to see how hiding anything from the API is going to help with that. (Also, getElementsAnnotatedWith is almost surely not the only method you'd need to consider, and quite possibly not the most important one. There is also RoundEnvironment.getRootElements, and then various other methods in the model, like PackageElement.getEnclosingElement which is AFAIK returning the owning module for source level >= 9, ExecutableElement.getModifiers() may include Modifier.DEFAULT since JDK 8, etc.) Jan > 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 >
