This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

In a previous article introducing Bazel, some students noticed a difference between Bazel and Gradle tools. In this article we answer that question.

From an employee at Bazel

Bazel and Gradle emphasize different aspects of the build experience. In some ways, their focus is mutually exclusive — Gradle’s requirements for flexibility and non-salience limit its build structure, while Bazel’s requirements for reliability and performance impose non-negotiable constraints.

Gradle values the same principles as Bazel, that is, the Gradle team values performance (incremental builds, parallel configuration and execution, Gradle daemons), correctness (content-based “up to date” checks), and reproducibility (rich support for declarative syntax, dependency on versioning, dependency on explicit declarations). Bazel respects the need for flexible project layout.

The difference is that Gradle wants to promote good practice, while Bazel wants to demand it. Gradle’s goal is to find a middle ground between the Ant experience (freely defining your own project structure with incoherent results) and the Maven experience (enforcing best practices that leave no room for different project requirements). Bazel believes that flexible project support is possible without sacrificing the workflow assurance that makes it powerful.

Neither of these philosophies is absolutely “right” — whatever tool is best for a project depends on the merits of that particular project.

Gradle overview

Gradle is a highly flexible system that makes it easy for users to build complete, reliable build processes with minimal constraints on how projects are organized. It does this by providing powerful building blocks (such as automatic dependency tracing and retrieval, tightly integrated plug-in support) and a common, Turing-complete, scripted interface that users can assemble as they wish.

Gradle highlights the following features:

  • Easy migration from other systems. Gradle can easily accommodate any project organization and easily implement any workflow structure. It understands Ant tasks locally and integrates Maven and Ivy repositories locally.
  • Highly extensible script model. Users implement all of the build logic by writing Groovy scripts. “Build” is simply the sequential execution of dependencies for common tasks that are essentially open, overridden, and extensible method definitions.
  • Rich dependency management. Versioning dependencies can be declared and automatically segmented from external code bases, local file systems, and other Gradle projects. Build output can also be automatically published to repositories and other locations.
  • Tightly integrated plug-in system. Plug-ins are simple task packages organized to facilitate the desired workflow. Many of Gradle’s “core” features are actually implemented through plug-ins (e.g. Java, Android). Plug-ins (at their own discretion) interact closely with the build script logic. The plugin provides deep access to Gradle’s core data structures.

An overview of Bazel

Bazel grew out of the need to build internal Google projects reliably and efficiently. Because Google’s development environment is so large and complex, Bazel offers a very strong guarantee of build integrity and a very low performance overhead in implementing a build.

This provides the basis for a powerful development workflow built around replicable builds, where “builds” become an abstract entity that can be referenced, repeated, passed to different machines, and passed to arbitrary programs and services so that every instance is exactly the same.

Bazel highlights the following features:

  • Correctness: Bazel builds are designed to always produce the correct output, period. If two users on different machines invoke the same build on the same commit using the same Bazel flag, they will see the same result. Incremental builds are just as reliable as clean builds, so the latter is largely unnecessary.
  • Performance: Builds are designed to execute as quickly as possible given available resources. The parallelism of tasks depends on their dependency chains. Unnecessary work is never performed (for example, “latest” tasks are always skipped). Work can be naturally assigned to remote actuators to overcome the limitations of local machines.
  • Reproducibility: Any instance built can be easily reproduced in any environment. For example, if an error report says that version X of software Y failed in production environment Z, developers can easily recreate it on their own machines and believe they are debugging the same thing.

From the Gradle team’s perspective

The global conversation around build automation is hot. Companies are learning that the ability to develop and improve software quickly is fundamental to competing in an environment where increasingly large and complex software is “eating the world.” Key driving factors include agile, SaaS software and API, multi-channel (such as Android, IOS, responsive Web, etc.), multilingual software (e.g., Scala, Go, etc.), services (such as Docker), micro vessel, user analysis method (such as the minimum viable product, A | B test, etc.) and the mixture of open and closed source library.

All of these emergent functions require systems to coordinate distributed developers on a large scale. With Bazel’s release, Google is joining a global conversation about important issues for businesses looking to automate high-speed builds.

Why do you do that?

The building field should be done by the smartest people and motivated by each other. New voices and solutions in enterprise building systems can enhance this global conversation; Google is a brilliant engineering organization with a unique perspective.

Among the Fortune 1000 companies, there is a lot of curiosity about how Silicon Valley’s leading companies are able to build large-scale software applications with such high frequency and with such rapid innovation. Innovations from such companies often contain valuable insights that can be transferred to other large software projects in due course.

What problem is Bazel trying to solve?

Bazel is a subset of the internal Google build system called Blaze. As a result, Bazel has evolved to solve a very big problem that is unique to Google:

Google’s J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc and Sanjay Bhansali of this research article well recorded the situation of Google: static.googleusercontent.com/media/resea…

The original internal Google build system greatly influenced the way people thought about builds. They are real innovators in terms of scalability.

Like many businesses, Google is multilingual. But unlike most code, Google has a source repository for all of it. Everything is released frequently from the head. This means that there is no way to change the integration pressures between teams and to separate things across organizational boundaries (locations, collaboration models, etc.)… Again, Google is one of the few organizations on the planet that can extend this model. Of course, in this case, if you don’t have complete parallelization. But this is an unusual backdrop.

Because of this large codebase, performance comes first and other requirements are secondary, especially those not related to Google. Most companies are not Google and have a much broader set of needs.

Bazel’s contribution?

Bazel’s invention confirms that the world’s best software companies care deeply about building the core capabilities of automation.

For those who want to compare Gradle and Bazel, the most revealing part of The Bazel FAQ is the team’s answer to the question: Why doesn’t Google use Gradle?

From Bazel FAQ

Bazel’s configuration files are much more structured than Gradle’s, which allows Bazel to understand exactly what each operation does. This allows for more parallelism and better reproducibility. It’s also important to note here that Google’s internal build system has been in development for over seven years, so the decision to build your own may have come from a more historical comparison.

There are two dimensions, one about “more structure” and results, thus increasing parallelism and better reproducibility. Both of these end goals are ideal for building systems.

Bazel refers to the low-level execution and toolchain model. Currently, Bazel captures more information about the relationship between the inputs and outputs of tasks/actions. This also makes it possible to parallelize reliably at the lowest level. These are huge improvements to the configuration model that can improve build performance when executed in a parallel environment.

Google’s focus on parallelization is probably the biggest global discussion of build performance. Making such a deep investment to build performance is a great act of industry leadership. Gradle is not as parallel as Bazel is today. It is executed in parallel at the project level, not at the task level. But in the coming months, that will be history. With our upcoming configuration and component models, Gradle is reliably and fundamentally parallel at the deepest level, including configuration operations.

In many ways, Gradle provides a powerful model in terms of structure and takes into account more aspects of parallel performance. In these respects, Gradle is already more structured than Bazel. Try creating a variant aware of Android builds with Bazel and you’ll see that there is no structure. You’re back in the Ant era. For these reasons, Gradle will be the default for Google Android. The Android team chose Gradle because of its differences from tools like Bazel(or Bucks or Pants). They were created for a specific context and purpose.

Because of the parallelism required to handle a very large monolithic source repository, Google clearly needed to build its own system when making this decision. But in the near future, Gradle will add this level of parallelism in addition to our other design features and considerations.

How does Gradle get involved in this conversation?

Gradle is keenly aware of the need to establish a standard build across the enterprise in order to regulate a highly heterogeneous set of frequently occurring projects, languages, platforms, delivery channels, and software development styles. We also recognize that extraordinary technologies and technologies from the software frontier can make a huge contribution to the rest of the world. Gradle has seen this deep commitment and leadership from our own customers, including Linkedin, Netflix, Google Android, and many others.

Together with the Google Blaze team, we recognize the power of a single, multilingual build system that provides a converged solution for unifying the enterprise build pipeline. However, we are acutely aware that most businesses don’t have the same monolithic approach as Google, and most don’t have the dedicated building services team and development culture that Google does. Serving a variety of enterprise customers created design requirements that influenced the development of Gradle.

Here are some observations from studying Bazel Alpha.

  • Bazel does not use a high-level declarative build language that makes builds easy for developers to use. At Google, this can be offset by professional services teams with building tools.
  • Not built for scalability. Since Bazel was built for just one customer, if Google’s engineers needed deep extensions, they had a build team they could incorporate into their own tools.
  • Speed is optimized around the idea that all source pass-through dependencies are stored in one large buyback; All libraries and tools are checked into this central repository. Most enterprises have more distributed dependency management requirements.
  • Bazel is *nix only, which does not run on Windows. That rules out a large number of potential businesses, including a large bank that we recently dubbed “51%.NET.”
  • An ecosystem without plug-ins.

Gradle’s goal has always been to find the ultimate path between performance, scalability, and the richness and usability of continuous integration process modeling.

Another important part of this conversation is about building extensibility and integration of the various tools in the toolchain. First, Gradle has deep integration with popular ides such as Eclipse, IntelliJ and Android Studio. Beyond these deep IDE integrations, the Gradle ecosystem is vast. Plugins Portal has over 300 + community plugins connected to various tools, platforms and systems for continuous delivery to the market + more in the wild, download 400 K/month, global and elite group of subcommitters of elite software and a strong alliance of organizations that use it strategically.

Where the conversation is going

The global discussion on build automation continues. Developers around the world are recognizing the need to move from decentralized, disparate, and unmaintainable build systems to a unified paradigm for continuous software delivery. Leading software companies in Silicon Valley and beyond are stepping up the game around the continuous delivery of software. Gradle is excited to be part of this global discussion and to work with world-class enterprises to enable them to have the core competencies of larger and more complex dynamic iterative software.

Gradle already has many satisfying answers that unify the build systems of hundreds of leading software companies. One of the core areas of improvement we are looking for in the coming months is the redesign of our configuration system, which will bring blaze parallelism to organizations looking to benefit from Gradle’s large ecosystem and diverse feature set.

We welcome a detailed review of our upcoming component model and distributed build capabilities, which should enable Gradle to bring Google-level distributed parallelism to our customers and other industries through open source.

Gradle vs. Bazel for JVM projects

The Gradle team has done an in-depth comparison of Gradle and Bazel for JVM projects, especially in terms of performance.

Introduction to the

Gradle has become the build tool of choice for projects in the JVM ecosystem, including Kotlin. It is the most popular build tool for open source JVM projects on GitHub. It is downloaded more than 15 million times per month on average and has been listed by Techcrunch as one of the 20 most popular open source projects in It. Many popular projects have migrated from Maven to Gradle, and Spring Boot is a prominent example.

Recently, we received an inquiry about the applicability of Using Google’s Bazel build tool in a JVM environment. The following is a detailed comparative performance analysis and evaluation of the key capabilities, leading to three main conclusions:

Despite Bazel’s reputation for performance and scalability, Gradle outperformed Bazel in almost all of the scenarios we tested. The Bazel optimization project costs a lot of build writing and maintenance. Gradle provides more attractive features and convenience for common use cases in JVM projects. Overall, the data and analysis clearly show that Gradle is a better choice than Bazel for most JVM projects. We’ll provide an equivalent comparison of Android projects in a future article.

At the same time, recognizing the unique advantages of individual tools in addressing the needs and requirements of specific developer ecosystems and specific use cases, we hope that building tool specialization and fragmentation will continue to be the norm for these ecosystems, such as Gradle and Maven.

With this in mind, Gradle Enterprise provides Gradle with more than analysis and acceleration capabilities. This allows users to benefit from faster, more reliable builds without having to migrate to any particular build tool. Gradle and Maven are now included, but Bazel and other tools will be included in the future. To learn more about Gradle support in Enterprise Gradle, Maven and Bazel build tools to accelerate technology, please watch the video “accelerated Maven build | Maven build cache technology and business cases to explain”.

performance

How the build system performs on a project depends on a number of factors. This includes the size and structure of the project, the tool chain used, and the workflow. In this section, we describe the methods for performing performance comparisons and the results based on representative scenarios.

About Performance Comparison

Gradle and Bazel have different approaches and concerns when it comes to performance optimization. For specific performance scenarios, it is easy to create some test projects to show that Gradle is much faster than Bazel, or vice versa. The question is always how applicable the results of such a test project are to the real project and, more importantly, to your project.

The way we do this comparison is by modeling common Java project types. From large repositories with millions of lines of code to small library/microservice projects. In this article, we will not discuss the pros and cons of various approaches to building code in a single large source repository or across many smaller source repositories. Both approaches have a significant footprint in the JVM ecosystem, and often in a single organization. Moving from one approach to another requires serious migration efforts and changes in workflow and culture. The JVM’s build system should support both approaches well.

Gradle has some advantages over Bazel compared to the time it takes to complete a build scenario:

conclusion

From what both the Bazel and Gradle teams say, Bazel is more of a Google incubated product for automated builds within the company, while Bazel is better in some scenarios (Android build, Java build, IDE integration) and will perform better than Bazel. So there is no need to worry about Gradle’s future. It will not be replaced. But do we still need to know Bazel? The answer is yes, because some of Google’s subsequent products will use Bazel build tools, and knowing Bazel will help us get started quickly with these new products. For example, the source code for TensorFlow is compiled based on Bazel, and we will share the TensorFlow Lite compilation for mobile platforms.

reference

  • Migrating from Gradle to Bazel

  • Gradle vs Bazel for JVM Projects

  • Bazel vs Gradle

  • Gradle Team Perspective on Bazel

Please feel free to discuss in the comments section. The nuggets will draw 100 nuggets in the comments section after the diggnation project. See the event article for details