When comparing Jam vs Gradle, the Slant community recommends Gradle for most people. In the question“What are the best open-source build systems for C/C++?” Gradle is ranked 11th while Jam is ranked 15th. The most important reason people chose Gradle is:
Android Studio's build system is an Android plugin for Gradle. What's more is that the Android Gradle plugin can be installed and run even on machines that don't have Android Studio, which enables you to build Android apps everywhere (for example continuous integration servers).
Ranked in these QuestionsQuestion Ranking
Pros
Pro Has a central package repository
A central repository provides more guarantees about the availability of the package. With requiring directly from repository urls, the entire project could potentially be taken down on a whim.
Pro Community is focused on client side javascript
Because Jam only manages Javascript and only works on the client side, you have the assurance that any packages listed are AMD compatible for asynchronous loading.
Pro Architecture independent
Jam's only a front-end package manager, the rest of your server can be on a different architecture or framework. No matter what the architecture, Jam will integrate easily with it.
Pro Provides the best AMD compatibility allowing for better asynchronous loading
Jam requires AMD (Asynchronous Module Definition), which means faster package loading, as it can be done asynchronously.
Pro Official Android Studio build tool
Android Studio's build system is an Android plugin for Gradle. What's more is that the Android Gradle plugin can be installed and run even on machines that don't have Android Studio, which enables you to build Android apps everywhere (for example continuous integration servers).
Pro Lots of plugins available
Gradle has hundreds of open source plugins available. This is extremely helpful for users who want to speed up their development.
Pro Dependency programming tool
Gradle is a dependency programming tool first and foremost. Gradle will make sure that all declared dependencies are properly executed for every random task that you execute in your setup. The code can be spread across many directories in any kind of file layout.
Pro Short scripts
Since Gradle does not use XML but it uses it's own DSL based on Groovy, Gradle scripts tend to be shorter than other build tools that use XML. Boilerplate code is also considerably small because it's DSL is designed to solve a specific problem: moving the software through its lifecycle starting from compilation into static analysis and testing, packaging and finally deployment.
Pro Integrates with Maven
Gradle can deploy to remote Maven repositories or even install to your local Maven repo.
Pro Built for continuous delivery
Gradle can be easily integrated with Jenkins to create a continuous delivery pipeline for any Java application.
Pro IDEA integration
Gradle has full integration with Jetbrains IDEA.
IDEA understands multi-module Gradle builds and automatically maintains the IDEA modules within the project.
You also have the option to run unit tests with either the built-in JUnit/TestNG test runner, or delegate running the test to Gradle using the same visualization as the built-in runner.
Pro Integration with Ant
Gradle integrates perfectly with Ant. Giving developers a lot of Ant's flexibility. You can run individual Ant tasks on Gradle or even entire Ant builds.
Pro Convention over configuration
Gradle follows the convention over configuration paradigm in order to make it easier for developers by having already made a number of decisions out of the box.
Pro Eclipse integration
Gradle has full integration with Eclipse through developer tools and plugins.
Cons
Con Forced AMD compatibility means fewer libraries
AMD is currently not as popular as CommonJS modules, which means if a library isn't supported, you'll have to deal with it yourself.
Con Can get slow for large builds
Since Gradle uses Groovy instead of XML for it's configuration scripts, it achieves a great deal of flexibility but unfortunately that comes with slower builds when the project gets large enough. This is because the entire Groovy script has to be recompiled for every build instead of simply being parsed.