Incremental compilation with literals in 3.4

[izeye]

Incremental Compilation, the Java Library Plugin, and other performance features in Gradle 3.4 said as follows:

Similarly, if the constant is changed, but that the dependents didn’t have a literal in their bytecode of the old value, we don’t need to recompile them: we would only recompile the classes that have candidate literals.

To find the usage of a literal, using its old value doesn't work if it is used for calculation and the result is inlined.

This was originally asked on the blog: https://blog.gradle.org/incremental-compiler-avoidance#comment-3178668770

/cc @melix

[melix]

Thanks @izeye

[melix]

Actually it seems we don't have the problem. Even if Java inlines the constant, class A is still visible in the constant pool table.

I made a simple test, and changing the constant value in A triggers a recompilation of B:

Incremental compilation of 2 classes completed in 0.034 secs.

[melix]

I'm not sure why, but it doesn't appear to be that simple (maybe it depends on the compiler version). The test case linked above fails.

[bjkail]

As of JDK-7153958, which was included in Java 8, javac includes a reference to the the constant field in the dependent class' constant pool. So, I think this bug seems to be valid for javac <7, and the constant tracking infrastructure seems unnecessary for javac >=8.

[melix]

It doesn't seem to be the case on all versions of Java 8, at least. I ran 8u91 and the test case still fails. Which is strange considering that it's supposed to be fixed in b68.

[melix]

So it's actually a combination of 2 bugs:

• with Java < 8, we don't recognize that A was referenced
• the compile classpath snapshotter, which computes the ABI of a component, ignores the constant values of API members

The latter is pretty serious.

[melix]

See #1476