Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Intellij build times are too long. Gradle not helping

I am frustrated by the long build time that IDEA needs before starting my application. I do use DCEVM to enjoy changing code on the fly better than plain hot-swap does, but this doesn't work if I really do need to start my applications multiple times.

IDEA is supposed to be able to have incremental compilation, but I'm not seeing it. I see no options to enable this. Start or starting a debug of the application, takes nearly half a minute. Must it take so long? In theory, IDEA has all the class files already generated, except for the source files that were just edited. IDEA ought to be able to fill in the few blanks, and get the application running almost instantly. What's the hold up, why does it insist it must re-compile every single source file again? ps. I'm using the Eclipse compiler in IDEA, so that it tolerates some source files not being compilable. I have to do that, because it is one giant tree of java files, where I can not control every one.

Then I saw that perhaps Gradle does have incremental compilation. So I thought to re-create my project, this time with Gradle. I am having a very difficult time figuring out how it works, how it integrates, what tasks are moved from IDEA to Gradle (if any). Even creating a simple skeleton test application with Gradle in IDEA is very frustrating. There are all sorts of fuzzy bits all over the place that leaves you guessing. The tutorials on Jetbrains are almost useless. I can't find one single clear to the point that just explains it in a nutshell how it works. I see some demos that says, click here, and here, and there, but the results on my end aren't the same as what I see outlined.

For instance, Gradle complains that it can't find the junit jar. Ok, so I go into the project settings, and attempt to add the junit jar to the classpath. Under Libraries, I then see an entry to "Gradle: junit:junit:4.11". But there is a second one: "junit-4.11". Why two? Can I delete one? Why is the one so verbal, colon this colon that, etc. So I add the junit jar files I have to both. But then in the Gradle Projects window, where I see the hierarchical breakdown of the gradle project setup, verification->test. This is then supposed to run the test class I did manage to create.

FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':testCompileClasspath'.
> Could not resolve junit:junit:4.11.
  Required by:
      xpert_client4:xpert_client4:1.0-SNAPSHOT
   > No cached version of junit:junit:4.11 available for offline mode.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

"Could not resolve junit:junit:4.11".

Gradle is extremely frustrating. If all I have to have, is to start a main() in a large project, why would I go through this trouble of using this gradle system that offers things I don't need? Why is it so convoluted, fuzzy, and confusing?

Same goes for an Android project. IDEA can compile and run an Android app without Gradle just fine. Simply avoid anything gradle when setting up, and it just works.

Plus there are all the things that one has to do to speed up the supposedly slow Gradle system. There is the daemon thing. Parallelize, and apparently you can set it in two ways (why). Configure on demand. Globalize. Minimize. minSdkVersion. Offline (oh no, not that Maven thing that pulls down jar files from the internet over and over). jCenter. Profile.... it goes on and on. All those workarounds, hacks, adjustments, tweaks. Is there anything to be gained by gradle-ifying a working IDEA project? Would I get faster build and startup times if I go through all this trouble? Can I avoid Gradle altogether, and forever (in the hopes that it doesn't somehow becomes mandatory).

I've been coding since the 80s. I've used all sorts of systems. I've build my own build systems. I'm not green here. I also hate having RTFM, if those FMs don't get to the point, and don't explain things well - as if the ones that wrote it, don't really understand it themselves - they know what buttons to press to get it going and that's it. I find this thing one of the most frustrating things I have seen in a long time. The previous horrible build system I've tried in the past, and have avoided like the plague since, is Maven. The lack of clear thinking with these systems is astounding.

So, aside from these frustrations, what I'm after is: is it worth figuring out Gradle and applying all the workarounds and tweaks, so that I may, once I go through this grief, enjoy faster build and startup times of my application?

Or, would I be better off, avoid Gradle altogether, and instead, do something like place the startup of my application in a loop, so that every time I exit that the application that it re-runs main(). I would then use DCEVM to code on the fly while possible.

Lastly, I forgot to mention. Enabling automatic build in IDEA works really badly. A build seems to always involve re-building every single file, over and over. And setting build to automatic, all it ends up doing is it redoing this in the background over and over. There is nothing that happens in an asynchronous way, where when I finish editing a source file, and start the debug of the application, where IDEA has done any of the building in the background ahead of time, because it redoes the whole thing again after every single tiny little code change. Plus it makes the CPUs spike to near 100% constantly. IDEA is a great IDE, but the whole compile thing is a total nightmare front to back.

like image 869
Mike Avatar asked Nov 04 '16 18:11

Mike


People also ask

Why is Gradle taking so long?

Check your Internet connection. If internet speed is very slow gradle build will also take long time to build. I check by change my wifi internet connection with another one good speed connection. Now build time is normal.

How do I fix Gradle sync issues in IntelliJ?

We can configure the settings for how IntelliJ IDEA syncs with Gradle by pressing the settings icon in the Gradle tool window, and selecting Auto-Reload Settings. We can set IntelliJ IDEA to automatically reload the project after "Any changes" in the build script files, so changes are automatically reloaded.


1 Answers

Make sure to disable anti-virus protection in your Gradle caches directory and your IntelliJ project directory. For me, this reduces Java compilation time dramatically, because of all the intermediate files and JARs associated with Java builds. Excluding those same directories from Windows Search indexing can also help.

As of September, 2020, this is the list of default directory locations that should be exluded from virus scanning and Windows search indexing, published here.

  • Gradle cache: %USERPROFILE%\.gradle
  • Android Studio projects: %USERPROFILE%\AndroidStudioProjects
  • Android SDK: %USERPROFILE%\AppData\Local\Android\SDK
  • Android Studio system files: %USERPROFILE%\.AndroidStudio<version>\system

I published some instructions on my blog for doing this for Windows Defender and Windows Search Indexing, which I'll repost here for completeness:

Windows Defender - How to Exclude a Directory

  1. Open Windows Defender Settings
  2. Click "Virus & threat protection"
  3. Click "Virus & threat protection settings"
  4. Scroll down to "Exclusions" and click "Add or remove exclusions"
  5. Click "Add an exclusion" and select "Folder" from the drop-down menu
  6. Navigate to the directory to be excluded, or paste its path into the "Folder" text-box, and click "Select Folder"

Windows Search Indexing - How to Exclude A Directory

  1. Open Windows Control Panel
  2. Search for "index" and choose "Indexing Options"
  3. Click the "Modify" button
  4. Under the appropriate drive letter, navigate to the folder you want to exclude, and make sure it is unchecked
  5. Double-check your work by verifying the directory shows up in the "Exclude" column of the "Summary of selected locations" table
like image 186
Mark McClelland Avatar answered Oct 23 '22 11:10

Mark McClelland