typetools / typetools/checker-framework
assignment.type.incompatible only with explicit "extends @Nullable Object" on type parameter
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 440
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 134
Description
I could be confused, but: I would expect class Map<K> and class Map<K extends @Nullable Object> to be equivalent. It appears that they're not. Here's some code that uses the longer version:
$ cat Map.java
import org.checkerframework.checker.nullness.qual.Nullable;
interface Set<E> {}
class Map<K extends @Nullable Object> {
Set<K> keySet = new KeySet();
class KeySet implements Set<K> {}
}
$ checker/bin/javac -processor org.checkerframework.checker.nullness.NullnessChecker Map.java
Map.java:6: error: [assignment.type.incompatible] incompatible types in assignment.
Set<K> keySet = new KeySet();
^
found : @Initialized @NonNull Map<K extends @Initialized @NonNull Object>.@Initialized @NonNull KeySet
required: @Initialized @NonNull Set<K extends @Initialized @Nullable Object>
1 error
However, if I tweak the class declaration to the "equivalent" shorter version, then the file compiles successfully. That's the behavior I would have expected in either case.
If I suppress the error, the .class files that I get for the long version is almost identical to that for the short version, according to javap -v. The only difference appears to be in the order of the RuntimeVisibleTypeAnnotations.
Source file and -version -verbose -AprintAllQualifiers output attached.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with the attached Map.java using checker/bin/javac and the NullnessChecker, comparing the explicit and abbreviated type-parameter declarations. Inspect the -version -verbose -AprintAllQualifiers output and the javap -v differences; the issue is done when both declarations receive equivalent checking behavior without the assignment.type.incompatible error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100