In stub files, <T extends Object> means <T extends @Nullable Object>

[cpovirk]

This might be intended behavior, but I found it surprising, and I didn't see documentation of it in the manual.

I had figured that, in a stub file, <T extends Object> would be interpreted as <T extends @NonNull Object>, as it is when compiling from source. But it seems to be interpreted as <T extends @Nullable Object>, as it is when reading an unannotated class file.

$ cat Caller.java 
import java.util.concurrent.ConcurrentHashMap;
import org.checkerframework.checker.nullness.qual.Nullable;

class Caller {
  void foo() {
    ConcurrentHashMap<@Nullable String, @Nullable String> m;
  }
}

$ cat ConcurrentHashMap.astub
package java.util.concurrent;

class ConcurrentHashMap<K extends Object, V extends Object> {}

Without the stub file, the Checker Framework uses the annotations from its built-in JDK stubs, which have the right bound:

$ checker/bin/javac -processor org.checkerframework.checker.nullness.NullnessChecker Caller.java
Caller.java:6: error: [type.argument.type.incompatible] incompatible types in type argument.
    ConcurrentHashMap<@Nullable String, @Nullable String> m;
                      ^
  found   : @Initialized @Nullable String
  required: @Initialized @NonNull Object
1 error

But when I include my stub file, the Checker Framework accepts the code, rather than rejecting it as I'd expected:

$ checker/bin/javac -processor org.checkerframework.checker.nullness.NullnessChecker -Astubs=ConcurrentHashMap.astub Caller.java
[compilation succeeds]

• Caller.java
• ConcurrentHashMap.astub
• output for compile that fails as expected
• output for compile that unexpectedly succeeds