Fix new errors due to automatic annotation of Class<T> types
The null analysis now automatically assumes that generic class types
(the "T" in Class<T>) are always @NonNull. See bug 477719.
This clears a bunch of warnings we had due to using Something.class
as parameters. Great!
However, this introduces a new problem. When a generic type parameter
is used both as parameter and as return value, and the client specifies
an annotation on the parameter during a call, the default behaviour is
to assume this annotation on the return type too.
In some cases this assumption is correct:
List<@NonNull String>.get() returns a @NonNull String
But in some others it is not:
Map<@NonNull K, @NonNull V>.get() should *NOT* return a @NonNull V.
Now some methods of the form:
V something(Class<V> type);
also follow this pattern, and the "automatic" @NonNull applied to V
also gets applies to the return value. In some (most?) cases this is
incorrect, and we have to supply external annotations to change the
return value to @Nullable. Just like we did for Map.get().
See bug 483143 for more information.
The return values of the following methods are now annotated as
@Nullable:
Class.getAnnotation()
DsfServicesTracker.getService()
IRemoteConnection.getService()
IRemoteConnectionType.getService()
and related null-checks were added.
Change-Id: I2c60835160a46e88ff293a5fd68774021c2b00a9
Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Reviewed-on: https://git.eclipse.org/r/61521
Reviewed-by: Hudson CI
Reviewed-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
Reviewed-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Tested-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
14 files changed:
This page took 0.028733 seconds and 5 git commands to generate.