3.16.0 introduces compilation failures around use of getClass()

[kennknowles]

(I wrote to checkerframework-discuss mailing list but also submitting here for exposure)

TL;DR: It seems that most or all uses of getClass() produce [super @KeyForBottom Void] and the uses in the code expect [super @UnknownKeyFor NullType] starting with checkerframework 3.16.0. Is there some specific change in 3.16.0 that introduces this that I can learn about? Does anyone know how to work around it?

Details:

I am trying to upgrade the checkerframework version used by Apache Beam. When I reach 3.16.0 I hit a new issue I do not yet understand how to fix. The issue persists through 3.27.0. There are checker framework crashes in 3.16.0 and 3.17.0 that are not relevant, so I will submit my question with 3.18.0.

• The pull request: Upgrade checker framework to 3.18.0 apache/beam#24406
• The build output: https://ci-beam.apache.org/job/beam_PreCommit_Spotless_Commit/23928/console

It seems most of the errors are roughly similar. Here is one (note that the method name is "TypeDescriptors.of" so it reads a little funny):

TypeDescriptors.java:354: error: [type.argument] incompatible type argument for type parameter T extends Object of of.
         (TypeDescriptor<T>) TypeDescriptor.of(instance.getClass()), supertype, extractor);
                                          ^
  found   : capture#464[ extends @UnknownKeyFor Object super @KeyForBottom Void]
  required: [extends @UnknownKeyFor Object super @UnknownKeyFor NullType]

The code in question:

public static <T, V> TypeDescriptor<V> extractFromTypeParameters(
    @NonNull T instance, Class<? super T> supertype, TypeVariableExtractor<T, V> extractor) {
  return extractFromTypeParameters(
      (TypeDescriptor<T>) TypeDescriptor.of(instance.getClass()), supertype, extractor);
}

There are quite a few other similar, typically simple, uses.

---

Commands to reproduce:

git clone https://github.com/apache/beam.git --branch 7c412bd19b36c598fd9abb934631c340827d8778
cd beam
./gradlew compileJava

Expectation: compile success as it succeeds with 3.15.0 and below.
Actual result: compile failure as above.

[smillst]

The defaulting annotations of lower bounds for the KeyFor Checker changed. The manual explains the defaulting, why you are seeing errors, and how to fix them. Let us know if we need to clarify anything.

[kennknowles]

Thank you! Giving it a try...

[kennknowles]

Follow-up question: what is the danger of the unsoundness introduced by suppressing keyfor warnings while keeping nullness warnings? Will all Map.get calls be treated as Nullable hence there is no unsoundness introduced?

[kennknowles]

I am asking this because the annotations in Beam for this case are getting esoteric enough that I worry about people pushing back on our use of checker.

[smillst]

Follow-up question: what is the danger of the unsoundness introduced by suppressing keyfor warnings while keeping nullness warnings? Will all Map.get calls be treated as Nullable hence there is no unsoundness introduced?

If your code has no @KeyFor annotations, then I don't think suppressing the keyfor warnings will introduce any unsoundness.

[kennknowles]

Awesome, that works perfectly for us at this time.