Develop Reference

How to force Intellij IDEA to use only one gradle daemon?

I know it may look like a duplicate of How to disable Gradle daemon in IntelliJ Idea?, but I don't want to completely disable gradle daemon. I just want to use only one daemon, not many of them.
The problem I have is that to successfully run some gradle tasks I have to give about 2GB RAM to gradle. And my system only had 8GB of memory.
The problem is that when I perform certain actions (I think it's "refresh gradle projects", there are 2 of them) - I sometiems get 2 or more gradle daemons running. Each consuming 2GB of memory.
Is it possible to use only one daemon or somehow automatically stop those extra daemons?

You can stop all currently running daemons with gradlew --stop. New deamons are only created if necessary. If e. g. a different Java version is used or different daemon arguments are needed and so on. You could maybe look with Sysinternals ProcessExplorer and compare the two processes to find where they differ to find a reason why two are created.

Android Studio using 100% CPU on an i7 processor for project Rebuild

My Windows 7 machine has a quad core i7 processor. When I Rebuild my project, it takes on average 25 seconds. And when I launch the app, it takes on average 36 seconds (before the app is uploaded to the device).
I have 588 files in my project's /src folder, which includes all of my java and xml code. I've got two .so libs each 5MB and 7 jars in my /libs folder.
See my attached screenshot. As you can see my CPU is maxed out at 100% the entire time. My iTunes music pauses, and I get a "Poor Performance" pop-up in the lower right hand corner of my windows taskbar. That's how bad it is.
I'm using Android Studio 1.2.1.1
Most of the time is spent during the preDex and dex operations.
Here's what I've tried so far (separately, I haven't tried them all together):
adding gradle.properties -> "org.gradle.daemon=true"
Power Saving
Mode Invalidate Caches /
Restart Global Gradle Setings -> Offline
work Compiler -> Make project automatically
Nothing has worked yet. I can't imagine that this is a common problem, am I right? Am I being too imaptient because this really is that much slower than Eclipse?
I guess my questions are:
Could this be due to the size of my jars or so files?
I tookover a project that had many nested views in XML files. Could this be causing a problem?
I'm really reaching for straws so if anyone has any information, esepecially why the dex operation is taking up so much CPU, that would be awesome.
I guess it goes without saying that this is happening if I edit an XML file, do a rebuild, and then launch the app. If there's nothing to clean and rebuild...
when I just do a Make Project... the average build time is 3 seconds.

Here are the three improvements I was able to make:
I was preDexing my JARs every time I built the project, so I found this solution:
dexOptions {
preDexLibraries = false
}
I was using the entire Google Play Services library:
compile('com.google.android.gms:play-services:+') {
exclude module: 'support-v4'
}
When all I needed was Google Cloud Messenger:
compile('com.google.android.gms:play-services-gcm:+') {
exclude module: 'support-v4'
}
In Eclipse, I would always do a Rebuild and then launch app with the play button. In Android Studio, now I am just doing a Clean and then launch app with the play button. Also the Run button in Android Studio does NOT work every time right after the Clean. This was causing what seemed to be delays because nothing was happening. So now I leave the Gradle Console open to make sure that the run button is working, and when it doesn't I just hit it a second time.
What I used to have:
Rebuild: 26 seconds
Launch: 36 seconds
Install: 15 seconds
and now:
Clean: 8 seconds
Launch: 22 seconds
Install: 15 seconds
which is a major improvement! Hopefully this helps someone else.

As stated on the tracker page for this issue, the team has identified this as the problem:
--parallel-threads only applies to project parallelization.
For android tasks that are running in parallel, we always create as
many threads as possible
From the page, it seems that they target release 1.3 to address this (see comment #13 there).
In the meantime, what has helped me to cope on Windows 7 is to set the CPU affinity for the Android Studio process (and its child processes) to spare at least one of the cores (as suggested by comment #9 on the page).
There are many ways to do this, but you might want to try the top-voted answer on this superuser question (which suggested to use Process Lasso) that appears to work well enough for me.

In addition to optimizations specific to Gradle (see below), I recommend that you try disabling anti-virus protection for your Gradle caches directory and your Android Studio project directory. For me, this reduces my build times by roughly 50%. Excluding those same directories from Windows Search indexing can also help.
Gradle optimizations I use, in ~/.gradle/gradle.properties.
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx6144m <-- Tweak this based on available RAM
org.gradle.caching=true
org.gradle.parallel=true
kotlin.incremental=true
Note that enabling caching means you sometimes have to explicitly clear your caches when switching branches. I run this script when I run into puzzling build issues.
#!/bin/bash
# Clean Android cache
./gradlew cleanBuildCache
# Clean Gradle cache, prompting for each directory
find ~/.gradle/caches -maxdepth 1 -name build-cache* -print -exec rm -rfI {} \;
# Clean Project
./gradlew clean
# Stop Gradle Daemon
./gradlew --stop

To be honest, Android Studio is hands down better than Eclipse because of the UI designer. The downside is that it uses gradle instead of Ant. Gradle is also better but slower - especially on Windows. It runs much better on Linux. If you haven't used Linux before, fear not. Linux Mint is a stable OS that has a UI that is similar to Windows. You'll be right at home in no time. It consumes fewer resources so that leaves more processing power for the gradle build. Make the switch. You'll never go back.

Gradle slows down computer during findbugs analysis of Java project

I'm using gradle 2.4 for a multi-project written in Java which has abount 15000 lines of code in 5 projects and i'm using Windows 7. I'm using the findbugs plugin in every sub-project.
The build itself is fast (enough) but while findbugs is running the reactivity of my PC is very bad. Most time the mouse hangs, opening websites takes a lot of time, music shutters, video hangs, etc.
If i reduce the priority of the corresponding java-process, everything is fine. For linux i found this https://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer . I tried the suggested -PtaskThreads=x option, but that didn't help.
Is there a way to set the priority of the java-process which does the findbugs stuff to 'idle' or 'background' programmaticaly? Preferable with pure gradle options since i don't want to use some tools like CPULimit.

Continuous testing with IntelliJ Idea

I'm looking for an IntelliJ IDEA plugin that would run my tests each time I change my code. I looked for such a solution and I found:
Infinitest, which works, but is inconvenient because I need to add the facet to each module, and it opens a new tool window for each module (which means 15 tool windows for me).
Fireworks - didn't work for me, maybe it just doesn't work with IDEA 14 (in its repo I can see that last changes were made in 2009). IntelliJ also reports that it throws exceptions.
There are lots of ways I could run all my tests (including writing a simple script for this), but I'm looking for a tool that would be smart enough to rerun failed tests first, and that would understand module dependencies (so after a change in some module it would run only tests of dependent modules).
I prefer free options, but if there's something paid for a reasonable price, I would accept it as well.

IntelliJ now actually has a Toggle auto-testin the run dialog. Just run a run-configuration and then select Toggle auto-testin the run dialog.
It's not as intelligent as you would have hoped. It just reruns when it detects changes.

I know this is a 3-year-old question but I think it will help people who face the similar problem in future. So I found out a way to enable SBT style auto test execution in IntelliJ studio.
We need to do 2 things to enable auto test execution.
Enabling auto project build - This can be done in settings by going into File -> Settings -> Build, Execution... -> Compiler and selecting "Build Project automatically".
Enabling "Toggle auto-test" in run dialog box
This will start auto testing. Although this works fine, it takes time to build the project even when my project is tiny so for larger projects it will certainly take very long time to complete the build and execute tests.
Reference: Original article which explains these steps

If you are OK running tests which cover a single method chosen by you, you can try this plugin (it is continuos in the sense that you make changes to a method, then click on the method and the plugin will run all the unit tests automatically which cover that method): https://plugins.jetbrains.com/plugin/15063-unit-test-coverage-history-runner

You can use the Intellij Teamcity plugin. Teamcity is a paid product but there is a free version which gives you 20 projects and 3 agents for free .
It has a remote run feature using which you can send in unchecked code to run tests before committing.
It also has options to run failed tests first
Usage instructions for Remote Run

What is the difference between manually building within an IDE and using Ant / Maven?

Hi most of the time i will build the Java Application using IDE option Build/Clean then Export JAR/WAR/EAR file to desktop after that will deploy in server using server admin url/console. But in some organizations will build application using ant/maven script in linux/windows. is there any difference buid using IDE and external script.

If you simply need to archive the entire project in your IDE as a WAR or EAR , then it does not really make difference if you build it through IDE or thorough ANT.
However there are certain scenarios where it requires more than just archival. For example you might want to create an EAR but do not want to include certain jars in it. Or you might want to remove all property files before creating the EAR. ANT gives you that flexibility. You can define your own build.xml and run it through ANT. It will create the EAR as defined in the build.xml.
Also it takes less time since its a automated process. So if you need to create WAR's or EAR's at a high frequency, You should probably use the scripts. They are going to save you a lot of time.
So basically automation and customization are the two main advantages of using ANTscripts

An external script like ANT can automate things for you. This may seem irrelevant when all you do is build a .JAR, but when you start to do more things it can be very helpful.
An automated build could do this for you:
Run your unit tests and create a report that you can view.
Compile your project ("Build")
Move the .JAR to a different directory.
Upload via FTP to your server.
This means that everything you currently do could be done by double-clicking an Ant script. Eclipse even has support for Ant so you can edit and run the script within your IDE.
Just an edit about the philosophy of automation. Let's say your current process takes about 15 minutes to build a .JAR and upload it to your server:
Once, 15 minutes.
Twice, 30 minutes.
Four times, 60 minutes.
You get the point. But wait, you say, writing an ANT script... that's more difficult - it might take 8 hours to learn about ANT and write a script that works.
And that is absolutely correct but the thing that makes automation grand is that now it takes 0 minutes to do your step. So, the process looks like:
Write ANT script: 480 minutes (8 hours)
Run ANT script: 0 minutes
So how do you know if you need automation? Simply think about how many times you will need to perform your manual process. If you'll only ever run it once then the comparison will be 15 minutes vs 480 minutes and you shouldn't write a script. But if you think you'll perform the process 40 times, then the comparison is 600 minutes vs 480 minutes and you would be better off writing a script.
(The above also excludes other positives about automation. For example, it's very easy to make mistakes [error in creating .JAR] when you do it manually - but the computer never makes mistakes once it's set-up correctly.)