Why can't gradlew build command compile and build only the things that have changed and make the process faster?

Question

The feature build automatically under the eclipse is much faster than the ./gradlew build .

My findings after some research is that it compiles and builds only the changed file and replaces it in build folder.

So why can't ./gradlew build command compiles and builds files that have changed and replace it in build folder and make the whole building process faster.

I have recently started using build automatically feature with hotswap agent + DCEVM.

Answer 1

Why can't gradlew build command compile and build only the things that have changed and make the process faster?

There's no dependable way how to determine what needs to be recompiled. For example, compile-time constants get inlined and there's no trace of where they come from in the class files (it can be found in the source files, that implies parsing them and losing time; it can be stored in some auxiliary files and some tools do it).

See the "Limitations" section of this for details.

The reason maybe is that they don't go through configure step of gradle.

Sure, but the configure step doesn't usually take that long.

Eclipse knows which files have changed

Good point (in a comment by holwgler).

---

Some time ago I spent some time trying to make my gradle compilation faster and I gave up. Eclipse is damn fast for many reasons:

• incremental compilation
• multithreading using all cores
• knowing all changed files
• having the whole compiler code optimized by the JIT
• probably caching file dependencies
• ugly highly optimized code

My "solution" is ignoring the problem. I do everything in Eclipse, except for integration tests (which take way longer than the compilation) and production builds (which are rare enough so I don't care).

You may want to read these performance tips .

---

To find out where the time gets spent, use

./gradlew clean; ./gradlew --profile jar

For me, 90% of the time is just :compileJava .