For API purposes, I'm all for setting on covariance as good enough. (Are there any existing checkers that do anything different? It sounds like the Checker Framework treats them as covariant by default (with an option to treat them as invariant).)

While we're on the subject, though, I looked into some of the questions that affect implementation code.

It's possible to create an array of a parameterized type with just a warning (well, 2 warnings):

List<String>[] a = makeArray(asList("foo"));
...

static <T> T[] makeArray(T... objects) {
  return objects;
}

GenericArrayCast2.java:10: warning: [unchecked] unchecked generic array creation for varargs parameter of type List<String>[]
    List<String>[] a = makeArray(asList("foo"));
                                ^
GenericArrayCast2.java:16: warning: [unchecked] Possible heap pollution from parameterized vararg type T
  static <T> T[] makeArray(T... objects) {
                                ^
  where T is a type-variable:
    T extends Object declared in method <T>makeArray(T...)
2 warnings

(And you can hide the one with @SafeVarargs -- not that it would be appropriate to do so on a method like this, which returns the array to the caller.)

But the more direct way of creating one is an error:

GenericArrayCast2.java:5: error: generic array creation
    List<String>[] a = new List<String>[1];
                       ^

So you have to use a wildcard and an unchecked cast:

List<String>[] a = (List<String>[]) new List<?>[1];

Or, if you don't mind having both an unchecked warning and a rawtypes warning, you can do it in less code:

List<String>[] a = new List[1];

Once you have a List<String>[], it's easy to set up a latent ClassCastException with no further warnings:

List<? super String>[] b = a;
b[0] = asList(0);
String s = a[0].get(0);

Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
  at GenericArrayCast2.main(GenericArrayCast2.java:10)

I, too, am not sure exactly how to apply all this to nullness yet. Certainly an attempt to create an array of non-null objects is at best "aspirational":

@NotNull String[] totallyDoesNotContainNull = new @NotNull String[1];

(If @NotNull is the default, then it could be omitted. Perhaps it would be surprising for a line with no nullness annotations and no preexisting objects to produce a warning or even error?)

(Another effect of the weird @Nullable String[] syntax is that it looks like you have to annotate the variable -- normally not required by flow-sensitive nullness analysis -- because in fact you're annotating the element type.)

Following the precedent of generics might mean requiring the following and issuing a warning:

String[] totallyDoesNotContainNull = (String[]) new @Nullable String[1];

(There's no "rawtypes workaround" in the case of String[].)

(Maybe it would be more honest for the code to store the array in a variable of type @Nullable String[], fill it in, and then perform the unchecked cast to @NotNull String[]. I suppose that libraries could even provide a casting helper that performs a runtime check of the contents, though that still can't protect against future mutation through the original variable (edit: or after assigning to a new variable of type Nullable String[]?).)

I was going to say that we could special-case creating an empty array, as in new Foo[0], but:

It's hard to imagine that that's worth a special case. (I guess a few people are stuck calling toArray(T[]), though, and maybe it helps them?)
I suspect that that can be turned into a latent NullPointerException by using Arrays.copyOf(empty, someNonZeroSize). (Not that we're trying to be 100% sound.) [edit: Is this solvable by making copyOf return a @Nullable T[] when given a T[]?]

[edit: another matter of implementation code: the type of Foo[].class: Class<Foo[]> or Class<@Nullable Foo[]>? See jspecify/jdk@71d8267]

Subtyping rules for array types #65

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions