s/or perfectly will look like it's broken to all its users/or perfectly *good code *will look like it's broken to all its users
(the problem of organizing your family babysitter calendar while also typing an email) -Tim On Thu, Jun 13, 2019 at 8:45 PM 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. > > 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 > > > -- http://timboudreau.com
