Build cache miss cross platform on classpath

Hi, we are experimenting with the build cache and so far the results are good on linux. Although we have some problems to get good cache hits between our windows and linux builds that build exactly the same code. At first we had 0% hits, after changing some gitattributes the source files are now having the same line endings (LF) en we now have cache hits for compileJava and compileTestJava which is great. Although we are not sure if we really want to have LF Lin endings on both java and linux since this brings us some other practical problems, so I wonder gradle will ever be made a bit smarter to ignore line endings when comparing? I understand this is not really a problem related to gradle, although it would be nice if I do not have to care about this.

for test and javadoc we have more problems to get cache hits. I found that the classpath input property on test and javadoc task is the only property that had a different build cache key comparing windows and linux:

13:50:35.100 [DEBUG] [org.gradle.caching.internal.tasks.DefaultTaskOutputCachingBuildCacheKeyBuilder] Appending inputPropertyHash for 'classpath' to build cache key: 18cb8dc9851080210ce60f2e78e8130e

Wen debugging the classpath, both seems to be equivalent, I mean, paths are different etc, but not really something that should matter. Even the order is the same.

How is the classpath property exactly hashed and compared on test and javadoc? And how is this different from compile because there is seems to work properly.

You may be seeing https://github.com/gradle/gradle/issues/1873, but this was an intermittent issue. Are you seeing cache hits for test and javadoc on the same OS?

For compilation, we ignore resources on the classpath and calculate an ABI for each class, but for test execution and javadoc generation, we look at everything and just take the hash of the bytes. If you have generated resources that could include absolute paths, dates, user names, OS names, etc, these things can be different between build agents and OSes, which would cause cache misses.

Just to be sure: You compared individual class files between Linux and Windows and they are the same? I could also imagine having different class files due to a difference in the minor version of Java used for compiling the class files.