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
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 <ebre...@gmail.com> 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
> ebre...@gmail.com
> > On June 5, 2019 at 2:17:47 PM CDT, Jan Lahoda <lah...@gmail.com> 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 <bwal...@musings.com> 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

Reply via email to