1

I get the error

Null type safety (type annotations): The expression of type 'String' needs unchecked conversion to conform to '@NonNull String'

at statement A of this class:

package org.abego.util;

public class MyClass {
    private String[] names = new String[]{"Alice", "Bob", "Charlie"};

    public String getName(int index) {
        String name = names[index];
        return name; /* statement A */
    }
}

The package org.abego.util defines the default nullness to be "@NonNull":

@org.eclipse.jdt.annotation.NonNullByDefault
package org.abego.util;

When adding @NonNull to the array definition:

package org.abego.util;

import org.eclipse.jdt.annotation.NonNull;

public class MyClass {
    private @NonNull String[] names = new @NonNull String[]{"Alice", "Bob", "Charlie"};

    public String getName(int index) {
        String name = names[index];
        return name; /* statement A */
    }
}

the warning at statement A goes away, however I get a new warning

The nullness annotation is redundant with a default that applies to this location

for the type @NonNull String[] in the array definition.

I found no way to make this code warning-free.

Could the 'redundant' warning be wrong? It is my understanding the NonNullByDefault declaration will make sure a type definition String[] will be interpreted as String @NonNull[], but not as @NonNull String[] or as @NonNull String @NonNull[]. So the explicit nullness annotation in @NonNull String[] is not redundant, but necessary to get the effective type @NonNull String @NonNull[].

(I am using Eclipse 4.5 (Mars) and jdk1.8.0_60.)

Udo Borkowski
  • 311
  • 1
  • 9

1 Answers1

1

Your expectations are correct. @NonNullBeDefault doesn't affect any details of an array type (unless you include DefaultLocation.ARRAY_CONTENTS in the annotation's value).

I believe this to be a variant of https://bugs.eclipse.org/440398

Thanks for the concise example, btw.

Stephan Herrmann
  • 7,963
  • 2
  • 27
  • 38
  • I agree the bug originally reported in https://bugs.eclipse.org/440398 and "my" bug are most likely related. But one should definitely add both code examples to the test suite for this bug as the different "default" handling may make a difference. – Udo Borkowski Sep 17 '15 at 13:07
  • Sure, I already copied a variant of your example to the bug, to be added as a regression test. – Stephan Herrmann Sep 17 '15 at 13:09
  • Sorry, I missed that. Thanks. – Udo Borkowski Sep 17 '15 at 13:12
  • I am currently making a large code base "nullable-clean". Most of the remaining warnings seem to be related a bug already reported on stack overflow (http://stackoverflow.com/questions/32617682/eclipse-external-null-annotation-for-java-lang-objectgetclass). Could you have a look? Thanks. – Udo Borkowski Sep 17 '15 at 13:16
  • Thanks for pointing me to the other question - I answered there. – Stephan Herrmann Sep 17 '15 at 13:40
  • 1
    As I have not enough reputation points to comment on "the other question": similar to getClass() also the expression `SomeType.class` should be considered to always be non-null. – Udo Borkowski Sep 17 '15 at 14:08
  • Class literals (`SomeType.class`) are already detected as non-null, as per https://bugs.eclipse.org/382789 fixed since Eclipse 4.3. LMK if you observe differently. – Stephan Herrmann Sep 17 '15 at 17:14
  • We already have a patch under review which fixes the problem in this question, it's in https://bugs.eclipse.org/467094 – Stephan Herrmann Sep 17 '15 at 17:17
  • Not sure if my class literal [problem](http://stackoverflow.com/q/32642992/3900879) is the same as Udo's, but I would appreciate it if you could take a look, Stephan. – Rusty Shackleford Sep 18 '15 at 02:44