Warn the user or even fail the build in case pre 1.8.0_202 Java is used

[vlsi]

Old Java versions have known issues that cause invalid bytecode produced for the perfectly valid Java code.
For instance: policeman-tools/forbidden-apis#173 (comment)

That might result in "invalid bytecode" being published to Maven Central, which is a very sad issue to have.

What do you think if the Checker Framework fails the build in case old Java 1.8 is used?
For instance:

• Fail the build in case java.version startsWith("1.8.0_") and the trailer is a numeric less than 202
• Provide an option to set the warning level to warn (or silence it completely)

I've added the check to Apache Calcite in apache/calcite@fd20efd, however, it would be nice if the Checker Framework included a similar check as well.

[mernst]

I agree that the invalid bytecode produced by broken compilers is a nasty issue.

If you compile code with the Checker Framework, you will not suffer any problems from invalid bytecode, no matter what version of Java you are using.
(Because of bugs in Java 8 javac, the Checker Framework never uses it. Following the instructions in the manual means that the user uses the Error Prone compiler, when running under JDK 8.)

I think your use case is:

• there is some code that someone compiled with a broken Java compiler (ie, not with the Checker Framework)

The Checker Framework doesn't have a way of knowing which compiler was used to compile which library, so I don't see how to issue this message in the appropriate way.

It also doesn't seem appropriate to issue the message when the Checker Framework is running, since that is the only situation when we can be sure that the bytecode is valid!

Could you clarify what warning you are suggesting? Thanks.

[vlsi]

Ah, you are right. The Checker Framework runs with a different Java version :(

[vlsi]

Supporting Java 1.8 becomes hard.
Gradle does not want to distinguish between minor compiler versions: gradle/gradle#15464
The Checker Framework does not participate with compilation of the bytecode.

It might probably make sense to reference known OpenJDK 1.8 issues for those who uses not that recent Java 1.8 and considers type annotations.

As a workaround, something like forbidden-apis could probably be used. That is a tool that parses the resulting bytecode and fails in case of a bug.

[mernst]

Related: #1928