Home » Language IDEs » Java Development Tools (JDT) » suppress null analysis for anonymous classes (using guava)
| suppress null analysis for anonymous classes (using guava) [message #1006762] |
Fri, 01 February 2013 17:16  |
|
Hi,
I want to use the null analysis newly introduced with JDT 3.8. It works
so far -- unfortunately it works too well.
I'm using Guava, and unfortunately the interface Function<X,Y> declares
a method
boolean equals(@Nullable Object object)
This Function interface is often implemented by anonymous interfaces. E.g.,
return Sets.newHashSet(Iterables.transform(mycollection,
new Function<MyClass, String>() {
@Override
@Nullable
public String apply(@Nullable MyClass input) {
return input == null ? null : input.getName();
}
}));
Now I got a nasty warning:
The method equals(Object) from Object cannot implement the corresponding
method from Function<MyClass,String> due to incompatible nullness
constraints
How can I get rid of this warning? I found three possibilities, and I
really do not any of them:
1) add @SuppressWarnings("null") to the top level class in which this
anonymous class is defined -- but I want null analysis for my classes,
and I'm using these Guava interfaces a lot...
2) override equals in anonymous class (which means also overriding
hashCode) -- only to get rid of the warning?!
3) use inner class instead of anonymous class -- again too much overhead
So, the problem seems to be that I cannot annotate an anonymous class,
can I?
Or can I tell the null analysis to ignore certain cases? Or are there
other possibilities?
Regards,
Jens
|
|
|
| Re: suppress null analysis for anonymous classes (using guava) [message #1006782 is a reply to message #1006762] |
Fri, 01 February 2013 19:33  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Jens,
We had a similar discussion regarding guava's Function [1], only, that time it concerned the annotation in apply().
As for suppressing this warning in Java 7- you need a declaration in order to add an annotation.
Instead of using an inner class you could also assign the anonymous instance to a local variable, which can carry the annotation.
Also the enclosing method could hold the annotation, of course.
The right solution will eventually be to fix bug 331651, so we can tell the analysis that Object.equals() promises to handle a @Nullable argument.
A cruel answer could be: tell our compiler *not* to use the same annotations which guava uses.
If you ask me: adding @Nullable to Function.equals *before* adding it to Object.equals was a bit over-eager.
Would it be an option for you to derive the anonymous functions not directly from guava's Function but from this one?
public abstract class MyFunction<S,T> implements Function<S,T> {
@Override
public boolean equals(@Nullable Object obj) {
return super.equals(obj);
}
}
Now all anonymous sub-classes can happily use this new equals method, which bridges between the annotated and the un-annotated parts of the world.
IMHO, that'd be the best solution for now, don't you think?
best,
Stephan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=385440#c2 (item 4)
|
|
|
| Re: suppress null analysis for anonymous classes (using guava) [message #1006789 is a reply to message #1006782] |
Fri, 01 February 2013 21:32 |
|
Hi Stephan,
thanks for the quick reply. The problem is that we use these annotations
and Guava in a rather big project for quite a while, and I only recently
activated the null-analysis (so far we used the annotations only for
documentation). So it is not really possible to change all usages (e.g,
by using an abstract class -- but thanks for the tip anyway), and we
have a lot of locations (we use the Guava Functions and Predicates a lot).
I'm afraid I will have to disable the analysis for the time being, and
only enable it once we have found a better solution. (Or only use it
from time to time to check new code).
I also discovered some other weird things, probably I should have a look
at bugzilla. E.g., given the following classes:
public ValueObject {
@Nonnull
public final String x;
public ValueObject(@Nonnull x) {
this.x = x;
}
}
public Client {
void bar(@Nonnull String s) { .. }
void foo(@Nonnull ValueObject v) {
bar(v.x);
}
}
also produces a warning in foo, as the x in v.x is not recognized as
@Nonnull, which seems quite odd to me.
> A cruel answer could be: tell our compiler *not* to use the same
> annotations which guava uses.
The problem is that we are using the same annotations as Guava, and I
want to have null-analysis for our code.
> If you ask me: adding @Nullable to Function.equals *before* adding it to
> Object.equals was a bit over-eager.
I agree with that. Actually, I'm wondering why they added the equals
method to the interface in the first place. In other situations, there
are no annotations in Guava, where it would be helpful. E.g., the
create-methods in Guava (such as Sets.newHashSet()), are not annotated
with @NonNull, which seems to create some problems as well. (Although
I'm not quite sure whether this is necessary. It should be derivable
from analyzing the data flow, should it not? Does this work with
binaries? I'm still a rookie with regards to null-analysis, it seems ;-)
). Maybe I can have a look at the Guava forum.
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=385440#c2 (item 4)
I will have a look at that.
Thanks again for the answer!
Cheers,
Jens
|
|
| |
| Re: suppress null analysis for anonymous classes (using guava) [message #1006818 is a reply to message #1006790] |
Sat, 02 February 2013 11:57 |
|
Hi,
On 01.02.13 22:45, Stephan Herrmann wrote:
> Just this second I got the announcement of Kepler M5 with this link
> http://download.eclipse.org/eclipse/downloads/drops4/S-4.3M5-201301302000/news/
>
>
> You might be interested in the very first item in that document :)
Ah! That's great! So fields weren't supported in 4.2? That explains some
warnings. Good news!
Since I already have the expert on the line: Are multiple annotations
supported (that is, different annotations meaning the same thing) in the
preferences? That is, we use @Nullable for fields and parameters, and
@CheckForNull to indicate possible null-return values.
Cheers,
Jens
PS Support for package JavaDoc in hovers is a nice thing, too. I often
have missed that.
|
|
|
| Re: suppress null analysis for anonymous classes (using guava) [message #1006823 is a reply to message #1006818] |
Sat, 02 February 2013 13:01 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Jens Von Pilgrim wrote on Sat, 02 February 2013 12:57Are multiple annotations
supported (that is, different annotations meaning the same thing) in the
preferences?
See https://bugs.eclipse.org/369079
We're considering to support one set of annotations per project / library. This item, however, has not been scheduled yet.
Quote:That is, we use @Nullable for fields and parameters, and
@CheckForNull to indicate possible null-return values.
Why would you want that?
The typical reason for wanting support for multiple sets of annotations is when you don't control all the code, viz some 3rd party already carries some null annotations. I don't see any reason for mixing different kinds in your own code, other than: confusing the reader 
cheers,
Stephan
|
|
|
Goto Forum:
Current Time: Thu Apr 18 01:03:57 GMT 2024
Powered by FUDForum. Page generated in 0.02171 seconds |
] 
Search
Help
Register
Login
Home
