After I implemented Gradle in our big project, bui...

# random

[elect]

After I implemented Gradle in our big project, building time went from 1s to 13-26s. Asking on the Gradle forum, everything boils down to compileJava which on Netbeans/Idea turns out to be blazing fast. There have been some suggestions, like divide the project into modules and activate build cache, but all of this appears to be light patches that only smoothes the problem (because every modification seems likely to trigger a full recompile anyway at module-level).
My big question is why Gradle (and company) lags so behind in terms of performances..

[tddmonkey]

Just to clarify - are you comparing doing compilation in your IDE vs using Gradle?

[elect]

yes

[gildor]

1s for incremental build time?

[elect]

yes

[gildor]

Have you checked build scans of your build?

[elect]

apparently IDEs will recompile just the very modified class (or very few), Gradle trigger full-recompilations or a couple of thousands

[elect]

yes, https://discuss.gradle.org/t/why-gradle-compilejava-is-much-slower-than-a-plain-project/32493/10 (also https://discuss.gradle.org/t/incremental-compilation-in-gradle-4-vs-5/31242)

[tddmonkey]

You’re not really comparing apples to apples there though. Try doing a full rebuild in your IDE

[elect]

I'm comparing developing environment conditions

[elect]

I really dont care if it's incremental or not within the IDE, the point the matters is the time to run the app after some sources modifications

[tddmonkey]

Except that Gradle isn’t a development environment, it’s a build too

[elect]

semantics, I think you know what I meant

[tddmonkey]

I do know what you mean, and I’m trying to explain the differences. They are not doing the same job so you can’t reasonably compare them

[elect]

I know, Gradle is much more, but for my simple case, building the application and running it, they are doing the same

[elect]

I'm seriously evaluating restricting Gradle usage just to:
- flatMap all the dependencies under a single folder
- run tests
- building RCs and Releases
and for all the dev in between plain project
has anyone ever consider something similar?

[tddmonkey]

I’m not sure what your workflow is now, but the typical usage I see is that actual development is handled inside your IDE with its internal compiler, everything else managed by Gradle

[gildor]

Incremental compilation for Java works in Gradle and if it doesn’t work, there is some bug

[gildor]

Maybe your build is just not reproducible for some reason, any way I would check build scan

[elect]

I cant believe I'm the first one to experience problems with incremental compilation

[elect]

anyway, the .\gradlew compileJava --info is clear, this is the output of a single String modification inside a class constructor:

Task ':compileJava' is not up-to-date because:

Input property 'source' file D:\DEVELOPMENT\EMM-Check\src\main\java\ec\gui\dialogs\vrserver\EC_VrClientListener.java has changed.

Created classpath snapshot for incremental compilation in 0.008 secs. 2061 duplicate classes found in classpath (see all with --debug).

Class dependency analysis for incremental compilation took 0.076 secs.

Full recompilation is required because 'EC_VrClientListener.java' was changed. Analysis took 0.087 secs.

[gildor]

okay, so it’s full recompilation

[gildor]

of course you not the first, but there are many reasons for that

[elect]

it looks so

[gildor]

What exactly did you change in this file?

[gildor]

also, which version of Gradle it is?

[elect]

just a String https://discuss.gradle.org/t/why-gradle-compilejava-is-much-slower-than-a-plain-project/32493/10?u=elect86

[elect]

last one 5.5.1

[gildor]

why a plain project without build tool is much faster?

I think it’s a wrong question. Because apparently you comparing full recompilation with incremental one.
The right question is “why incremental compilation doesn;’t work”

[elect]

I cant argue that

[gildor]

what about this thing with public constant?

[elect]

I tried a super bare class, nothing changed

[gildor]

even with private method change? (as the most encapsulated change)

[elect]

just tried, with private methods seems working

Task ':compileJava' is not up-to-date because:

Input property 'source' file D:\DEVELOPMENT\EMM-Check\src\main\java\ec\utils\code\EC_CodeCount.java has changed.
Created classpath snapshot for incremental compilation in 0.007 secs. 2061 duplicate classes found in classpath (see all with --debug).
Class dependency analysis for incremental compilation took 0.079 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 1 classes completed in 0.225 secs.
:compileJava (Thread[Execution worker for ':',5,main]) completed. Took 0.468 secs.

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed

[elect]

so, actually the right question would be, why incremental compilation is much more effective on plain projects

[gildor]

no, question is still the same

[gildor]

but more specific “why incremental compilation doesn’t work with specific change”

[cedric]

It’s very easy to defeat incremental compilation by accident and not easy to track. Whenever your build generates some Config.java, Version.java or captures the current git branch or sha, chances are high that you’re being hit with full rebuilds.

[gildor]

True, but if it works with private method change than it probably not the case, but anyway worth to investigate

[elect]

@gildor exaclty my though..
now my big problem is how to investigate.. compileJava seems like a black box

[gildor]

for sure. I would reproduce it and report an issue