remove annotation in NetBeans..

[Brad Walker <bw...@musings.com>]

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.

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

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 <ni...@gmail.com> wrote:

>
>
> On Thu, Jun 13, 2019 at 2:22 PM Jan Lahoda <la...@gmail.com> wrote:
>
>> On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <ni...@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

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

On Sat, Jun 15, 2019 at 7:26 AM Jan Lahoda <la...@gmail.com> wrote:

> On Sat, Jun 15, 2019 at 12:39 PM Tim Boudreau <ni...@gmail.com> wrote:
>
> > > > 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?
> > >
> >
> > If you accept my second suggestion (allow version- or language-feature-
> > specific processors), then it allows you to have separate module-aware
> > (whatever it does) and non-module-aware implementations.  Most annotation
> > processors probably won't need that, but it solves the corner case for
> one
> > that does - instead of screaming at users that their Java version is too
> > new, the compiler can just pick the appropriate implementation.
> >
>
> Well - the APs can do that, if they wish, right? (And, frankly, it is not
> that difficult - it is quite possibly easier than maintain several copies
> of the AP, just to have one for "old" JDKs and one for "new" JDKs.)
>

Yes, but they cannot eliminate the warning.

And the whole point is, if the annotation processor is not broken:
 - the annotation processor author should not have to "fix" it
 - users should not be scared by warnings when nothing is wrong


> >
> > For that matter:  You're the Java compiler (yes, you, Honza, are
> personally
> > the Java compiler! I imagine you have days where you feel like that :-)).
> >
>
> Well, even if I accepted that I am the Java compiler (which, frankly, I am
> not really), what you are talking here is JSR 269 *design*. And I am surely
> not that. You are redesigning how APs work here, and, frankly, there are
> different venues to do that than this list! I might be the one implementing
> the design, but not the one doing the redesign.
>

True enough.

-Tim

Re: Re: remove annotation in NetBeans..

[Jan Lahoda <la...@gmail.com>]

On Sat, Jun 15, 2019 at 12:39 PM Tim Boudreau <ni...@gmail.com> wrote:

> > > 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?
> >
>
> If you accept my second suggestion (allow version- or language-feature-
> specific processors), then it allows you to have separate module-aware
> (whatever it does) and non-module-aware implementations.  Most annotation
> processors probably won't need that, but it solves the corner case for one
> that does - instead of screaming at users that their Java version is too
> new, the compiler can just pick the appropriate implementation.
>

Well - the APs can do that, if they wish, right? (And, frankly, it is not
that difficult - it is quite possibly easier than maintain several copies
of the AP, just to have one for "old" JDKs and one for "new" JDKs.)


>
> For that matter:  You're the Java compiler (yes, you, Honza, are personally
> the Java compiler! I imagine you have days where you feel like that :-)).
>

Well, even if I accepted that I am the Java compiler (which, frankly, I am
not really), what you are talking here is JSR 269 *design*. And I am surely
not that. You are redesigning how APs work here, and, frankly, there are
different venues to do that than this list! I might be the one implementing
the design, but not the one doing the redesign.

If you wanted to be completely insane about it, you could have an
> annotation processor that analyzes Processor sources, and actually writes
> out a file somewhere in META-INF that describes what APIs that processor
> calls and what classes it uses, so the compiler could intelligently decide
> whether to warn about the source version or not.  If, say, the supported
> level is 9 and you're compiling on 10, and there were no changes to
> ElementKind, you know it will not see elements it doesn't understand, so,
> no need to warn.  Most of the time, there won't be a reason to warn - just
> occasional cases where there are really big changes.
>
>
> > 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.
> >
>
> Which is why I suggested either a way to have version-/feature- specific
> annotation processors when there is no other way to deal with it.
>
> 99% of annotation processors won't have this (or any other) problem - which
> is why printing a warning in case the annotation processor *is  *in that 1%
> is not a good way to deal with it.
>
> This thread shows that really clearly:  We have people wanting to make
> pointless and potentially-harmful code changes (at the very least,
> returning SupportedSourceVersion.latest() means the compiler will have to
> actually instantiate all such annotation processors to call that method,
> slowing down build speed, perhaps a lot) just to hide a warning that, for
>

I think this is an exaggeration - the source level only needs to be check
on APs that are already instantiated (and is done by - simply - invoking
the method). @SupportedAnnotationTypes may allow skipping instantiation of
some APs, but difficult to see how supported source version could, in the
current design.


> most annotation processors, really should be ignored.  A warning that is
> wrong 99% of the time is a torture device.
>
>
> > > 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.
> >
>
> Well, I wasn't just suggesting hiding elements that shouldn't exist from
> the API - but make let me make that explicit:  If you were an annotation
> processor supporting JDK 8, the containing element of a package would not
> be a Module, and if you were on JDK 7, ExecutableElement.getModifiers()
> would not return Modifier.DEFAULT.  Internally, you could do that with
>

I can't see how this helps with the issue I am trying to describe: i.e. the
AP *not* doing something it should be doing, because it does not understand
the source code the user is compiling. Hiding stuff in the API is not
really going to help, checking methods that the APs is calling is not
really going to help either (or in a very, very, limited fashion). The
issue is that the AP is *not* calling methods (or checking for situations)
it should be calling (or checking). Because, simply, the features in the
source code that is being compiled (possibly) didn't exist at the time the
AP was written.

Jan

annotations that indicate the source level an element, modifier or whatever
> was introduced in and some generic filtering collection implementations
> that hide things those things, and a ThreadLocal context for the
> currently-being-run annotation processor's source level - implementing this
> would not be that terrifying or ugly, and could be made declarative enough
> that such changes don't require big code changes throughout the compiler.
>
> So, that's two different ways javac could do a better job of this:
> 1. Present processors with the API they expect, hiding things that might
> break it.
> 2. Version/feature-specific annotation processors, so you can have a
> fallback for older JDKs.
> 3. Have javac, which has complete information about the processor when the
> processor itself is being compiled, do some flow analysis and emit some
> metadata that can be used when the annotation processor is about to be
> called, to decide whether to issue the warning or not.
>
> Any or all of these would improve the current situation.
>
> -Tim
>
>
> > (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
> > >
> >
>
>
> --
> http://timboudreau.com
>

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

> > 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?
>

If you accept my second suggestion (allow version- or language-feature-
specific processors), then it allows you to have separate module-aware
(whatever it does) and non-module-aware implementations.  Most annotation
processors probably won't need that, but it solves the corner case for one
that does - instead of screaming at users that their Java version is too
new, the compiler can just pick the appropriate implementation.

For that matter:  You're the Java compiler (yes, you, Honza, are personally
the Java compiler! I imagine you have days where you feel like that :-)).
If you wanted to be completely insane about it, you could have an
annotation processor that analyzes Processor sources, and actually writes
out a file somewhere in META-INF that describes what APIs that processor
calls and what classes it uses, so the compiler could intelligently decide
whether to warn about the source version or not.  If, say, the supported
level is 9 and you're compiling on 10, and there were no changes to
ElementKind, you know it will not see elements it doesn't understand, so,
no need to warn.  Most of the time, there won't be a reason to warn - just
occasional cases where there are really big changes.


> 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.
>

Which is why I suggested either a way to have version-/feature- specific
annotation processors when there is no other way to deal with it.

99% of annotation processors won't have this (or any other) problem - which
is why printing a warning in case the annotation processor *is  *in that 1%
is not a good way to deal with it.

This thread shows that really clearly:  We have people wanting to make
pointless and potentially-harmful code changes (at the very least,
returning SupportedSourceVersion.latest() means the compiler will have to
actually instantiate all such annotation processors to call that method,
slowing down build speed, perhaps a lot) just to hide a warning that, for
most annotation processors, really should be ignored.  A warning that is
wrong 99% of the time is a torture device.


> > 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.
>

Well, I wasn't just suggesting hiding elements that shouldn't exist from
the API - but make let me make that explicit:  If you were an annotation
processor supporting JDK 8, the containing element of a package would not
be a Module, and if you were on JDK 7, ExecutableElement.getModifiers()
would not return Modifier.DEFAULT.  Internally, you could do that with
annotations that indicate the source level an element, modifier or whatever
was introduced in and some generic filtering collection implementations
that hide things those things, and a ThreadLocal context for the
currently-being-run annotation processor's source level - implementing this
would not be that terrifying or ugly, and could be made declarative enough
that such changes don't require big code changes throughout the compiler.

So, that's two different ways javac could do a better job of this:
1. Present processors with the API they expect, hiding things that might
break it.
2. Version/feature-specific annotation processors, so you can have a
fallback for older JDKs.
3. Have javac, which has complete information about the processor when the
processor itself is being compiled, do some flow analysis and emit some
metadata that can be used when the annotation processor is about to be
called, to decide whether to issue the warning or not.

Any or all of these would improve the current situation.

-Tim


> (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
> >
>


-- 
http://timboudreau.com

Re: Re: remove annotation in NetBeans..

[Jan Lahoda <la...@gmail.com>]

On Sat, Jun 15, 2019 at 4:24 AM Tim Boudreau <ni...@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
>

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

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

Re: Re: remove annotation in NetBeans..

[Jan Lahoda <la...@gmail.com>]

On Fri, Jun 14, 2019 at 2:45 AM Tim Boudreau <ni...@gmail.com> wrote:

> On Thu, Jun 13, 2019 at 2:22 PM Jan Lahoda <la...@gmail.com> wrote:
>
> > On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <ni...@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.
>

Of course, the changes are as compatible as possible. But, as the Java
language evolves, the model evolves as well, correct? Most processors can
(hopefully) handle most of the changes, but, as the processor can do
whatever it likes, it is difficult to say that all processors are fine.


>
> 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.
>

Not necessarily - if you are sure the processor can handle the new models,
simply return SourceVersion.latest() from
Processor.getSupportedSourceVersion().


> 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.
>

The model does evolve in practice (default interface methods in 8, modules
in 9, etc.).

Breakages of annotation processors are hopefully rare, but consider for
example our ServiceProviderProcessor (which handles the @ServiceProvider
annotation). I doubt it works correctly (or even can work correctly) when
compiling a named module. But when compiling for the unnamed module, it is
fine even for (currently existing) JDK 9+.


>
> 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?

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
>

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

On Thu, Jun 13, 2019 at 2:22 PM Jan Lahoda <la...@gmail.com> wrote:

> On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <ni...@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

Re: Re: remove annotation in NetBeans..

[Jan Lahoda <la...@gmail.com>]

On Thu, Jun 13, 2019 at 7:29 PM Tim Boudreau <ni...@gmail.com> 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 <eb...@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
> > Ebresie@gmail.com
> > > On June 5, 2019 at 2:17:47 PM CDT, Jan Lahoda <la...@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 <bw...@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
>

Re: Re: remove annotation in NetBeans..

[Tim Boudreau <ni...@gmail.com>]

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 <eb...@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
> Ebresie@gmail.com
> > On June 5, 2019 at 2:17:47 PM CDT, Jan Lahoda <la...@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 <bw...@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

Re: Re: remove annotation in NetBeans..

[Eric Bresie <eb...@gmail.com>]

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
Ebresie@gmail.com
> On June 5, 2019 at 2:17:47 PM CDT, Jan Lahoda <la...@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 <bw...@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.
> >

Re: remove annotation in NetBeans..

[Jan Lahoda <la...@gmail.com>]

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 <bw...@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.
>