Truth 1.1+ depends on Java 8 bytecode

[ejona86]

org.checkerframework:checker-qual:3.13.0 is compiled to Java 8 bytecode seemingly making Truth incompatible with Java 7. It seems Truth is still compiling to Java 7 bytecode, so this seems likely an oversight. This was not a problem in 1.0.1 and I didn't notice a mention in the release notes.

I'll note that I've not tested whether Truth is actually incompatible with Java 8 because Gradle notices the incompatibility early in the build:

Execution failed for task ':grpc-context:compileTestJava'.
> Could not resolve all files for configuration ':grpc-context:testCompileClasspath'.
   > Could not resolve org.checkerframework:checker-qual:3.13.0.
     Required by:
         project :grpc-context > com.google.truth:truth:1.1.3
      > No matching variant of org.checkerframework:checker-qual:3.13.0 was found. The consumer was configured to find an API of a library compatible with Java 7, preferably in the form of class files, and its dependencies declared externally but:
          - Variant 'apiElements' capability org.checkerframework:checker-qual:3.13.0 declares an API of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 8 and the consumer needed a component compatible with Java 7
          - Variant 'javadocElements' capability org.checkerframework:checker-qual:3.13.0 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them preferably in the form of class files)
          - Variant 'runtimeElements' capability org.checkerframework:checker-qual:3.13.0 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 8 and the consumer needed a component compatible with Java 7
          - Variant 'sourcesElements' capability org.checkerframework:checker-qual:3.13.0 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them preferably in the form of class files)

[cpovirk]

Sorry, yes, an oversight. This is fallout from e71b57b, which is itself fallout from 10ee459....

The Right Thing would be for us to migrate back to jsr305 until we're ready to drop Java 7 support. We... could do that :( What we're doing now is definitely wrong. But... could we be so lucky that no one else cares? e71b57b was part of 1.1, so we made it 7 months. And probably things are mostly OK at runtime, since unrecognized annotations are mostly ignored?

But if this causes you some grief, we could probably fix it in a couple hours. Let me know. (Maybe you could exclude the dep, much as I normally discourage that?)

Regardless, I'll retroactively mention this in the release notes for 1.1.

And thanks for reporting this. This is the kind of problem that ideally we would detect ourselves (though thankfully our dependencies are mostly annotations and projects with very conservative Java-version requirements).

[ejona86]

I don't care much, because gRPC uses Java 8+ to test anyway. Dropping Java 7 support is "soon," so just sitting on the older version of Truth is certainly easiest. But excluding the "bad" dependency is probably pretty easy for us, so I'll see if I can do that instead. Excluding checker-qual has the benefit of not causing trouble if there's a Truth-related LSC internal to Google.

I mainly reported because I thought you'd like to know. I'm actually surprised Gradle caught this, as otherwise we wouldn't have noticed. It seems to be because Gradle Module Metadata told it things would break, so props to Gradle there.

Closing since release notes were updated and that's good enough for me. I'll report back if I run into undue trouble. I guess if you don't hear back from others soon (? it's already 7 months...) you can easily swap to Java 8 bytecode!

[cpovirk]

Great, thanks. And yes, aside from the part of me that didn't want to know about this, I did want to know this :) It's certainly encouraging for a Java 8 future. Neat that Gradle told us about it.