On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <[email protected]> wrote:
> We should look for a way to suppress this warning - it's silly - not alter > code to get rid of it. There is an open JDK bug to make it lint-aware, > since it really is complaining about something completely harmless: > https://bugs.openjdk.java.net/browse/JDK-7184902 > > Say I write an annotation processor, and I (naturally) want it to work on > as many projects as possible, so I have it support the lowest common > denominator - say JDK 7's source level, and generate code that will compile > on JDK 7. That's a perfectly reasonable thing to do. > > Now someone uses my annotation processor on *any JDK > 7*. They will get > an annoying warning. Are they supposed to only ever use JDK 7? Of course > not - that's ridiculous. > > Java is source backward-compatible, so it is completely harmless to > generate JDK7-compatible sources or have an annotation processor say that > it supports source level 1.5 or whatever the author wants - those sources > will compile just fine on JDK-whatever. The warning reflects a > misunderstanding of what "backward compatibility" means. I don't know what > problem the person who wrote it thought they were solving - the only case I > 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". Jan can think of where this might be an issue is if you were generating JDK 1.3 > compatible code that used "enum" as an identifier. That kind of > compatibility break - adding a keyword - is unlikely ever to occur in the > future (annotations solved it nicely with @ which is not a legal leading > character in an identifier, and the same pattern can be used in the > future). Yet the compiler emits warnings as if that were the common case. > That is a mistake. > > The fact that the warnings punish developers who use newer versions of Java > is a bug, not something we should treat as meaningful, or worse, make code > changes to try to get around it. A productive way to address it would be > to root around in the javac sources and see if there's any way to simply > turn it off. Rooting through every annotation processor and increasing its > supported source level just makes that annotation processor less useful to > anyone using it on an older JDK in a library, is not truthful (the > processor in fact could support older source levels), and is an utter waste > of everyone's time. Don't do it. > > If beginning developers are scared of build warnings, use it as a teachable > moment that some build warnings are nonsense and you actually have to read > and understand them and figure out what's worth paying attention to - > that's reality when you're using tools written by lots of different people > with different ideas about what's important - you have to read, look things > up, develop your own judgement, and not just skate by on "no output = good, > any output = bad". > > -Tim > > > On Thu, Jun 6, 2019 at 7:59 AM Eric Bresie <[email protected]> wrote: > > > Why is this used to begin with? Is there a Java 7 specific dependency of > > some type requiring it? > > > > If so does it need to but updated with newer Java equivalents and remove > > the implied java 7 dependency? > > > > For example, in newer Java version they have moved away from previously > > provided package which where supposed to be more internal used and needed > > to be migrated to new module public based versions. > > > > Eric Bresie > > [email protected] > > > On June 5, 2019 at 2:17:47 PM CDT, Jan Lahoda <[email protected]> > wrote: > > > But does removing the annotation really help? Won't it cause more > > warnings? > > > Generally, this is not a NetBeans annotation, it is a javac/JDK > > annotation > > > and is used by JDK. I guess the options I see are: > > > -update the annotations to RELEASE_8 > > > -override the getSupportedSourceVersion() in all the annotation > > processors > > > to return javax.lang.model.SourceVersion.lastest(). (Which might mean > the > > > processor will see source code model for new features and behave weird > > > without any warning whatsoever, but in most cases, this should be OK.) > > > -try something clever, like inferring the supported source version from > > the > > > source level of the module that contains the processor. Not sure if > > there's > > > some advantage to that, though. > > > > > > Jan > > > > > > > > > On Wed, Jun 5, 2019 at 7:00 PM Brad Walker <[email protected]> > wrote: > > > > > > > I'm trying to clean up various build warnings.. I need some > > help/advice on > > > > one of them. > > > > > > > > In particular, we have 3160 cases of the following warning: > > > > > > > > [repeat] warning: Supported source version 'RELEASE_7' from > annotation > > > > processor '<java file location here>' less than -source '1.8' > > > > > > > > In looking at this in more detail, I noticed the following Annotation > > is > > > > causing this warning.. > > > > > > > > @SupportedSourceVersion(SourceVersion.RELEASE_7) > > > > > > > > This annotation is in 70 different files. > > > > > > > > In looking at this closer, it really looks like we are not enforcing > > the > > > > use of this annotation. Also, we mandate Java 8 as the minimum > > supported > > > > release. > > > > > > > > So we either need to update all the files to at least > > > > SourceVersion.RELEASE_8. But, if we do this, this we will be back to > > having > > > > the same warning when compiling using a newer version of Java. Or we > > could > > > > just remove the annotation. > > > > > > > > My vote is for removing the annotation. It creates a LOT of warnings. > > The > > > > NetBeans sources has a lot of places where it completely ignores the > > > > annotation and just calls into library directly like this: > > > > > > > > if (javac.getSourceVersion().compareTo(SourceVersion.RELEASE_7) >= > 0) { > > > > > > > > Before I put forth the effort to remove the annotation, I wanted to > > get a > > > > pulse from the group if this is the right course of action? > > > > > > > > I would appreciate any comments/insight that I might be missing.. > > > > > > > > Thanks. > > > > > > > > -brad w. > > > > > > > > > -- > http://timboudreau.com >
