@Donal -
Well, if you have code like...
public void someMethod(@Nullable Object value) {
Assert.notNull(value, "...");
value.invokeSomeMethod();
...
}
The compiler will often *warn* you that value might be null without a
proper null check. That is, not all IDEs recognize "valid" null checks,
particular if they are using some API/framework like AssertJ, perhaps. For
example:
assertThat(value).isNotNull();
NOTE: *AssertJ* use is valid and common outside of just tests!
Usually the compiler only recognizes the assert keyword, i.e. ...
assert value != null : "...";
But the problem with Java assertions is you need to explicitly enable them,
therefore most users use lib or framework/API (e.g. like *AssertJ*).
I think other valid uses of the @SuppressWarnings annotation includes.
*"rawtypes"*
*"unchecked"* // particular around casting when the compiler is not smart
enough to figure it out though you know it is safe; usually an instanceof
check avoids these...
*"unused"* // arguable, though
Of course, use all of these judiciously and only when absolutely necessary
or certain.
I don't think it is OK to suppress deprecations (among other warnings)
since those should be addressed!
-j
On Fri, May 8, 2020 at 12:44 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
>
>
> > On May 8, 2020, at 12:41 PM, Donal Evans <doev...@pivotal.io> wrote:
> >
> > Is there a consensus on what constitutes a benign warning? I think the
> only
> > times I use @SuppressWarnings is in parameterized tests to suppress the
> > unused method warning for the parameters method, or for unchecked casts,
> as
> > below:
> >
> > PartitionedRegion detailRegion1 = mock(PartitionedRegion.class);
> > when(cache.getRegion(regionPath1)).thenReturn(detailRegion1);
> >
> > where the thenReturn() would complain, since it's expecting to return a
> > Region<Object, Object>.
> >
> > Would these be considered things that could safely just be ignored (and
> so
> > for which I can turn off inspection), or is the use of @SuppressWarnings
> > here warranted?
>
> This is a legitimate suppression. There is no other way to correct the
> dysfunctional nature of Java Generics than to @SuppressWarnings. In this
> case though only that statement should be suppressed.
>
> -Jake
>
>
--
-John
Spring Data Team
