6 ms·

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much mo

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

m0zg 7y ago
I don't work in Java, but just so you know, you can define Maven deps in your WORKSPACE file, and Bazel will automatically download and cache them (and their dependencies) much like Maven would. The rest of the build is trivial to set up.
oweiler 7y ago
I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.
- jingwen 7y ago
  The Bazel team published official rules for managing transitive dependencies from Maven: https://github.com/bazelbuild/rules_jvm_external https://github.com/bazelbuild/rules_jvm_external There are also community created solutions like https://github.com/johnynek/bazel-deps https://github.com/johnynek/bazel-deps, and https://github.com/square/bazel_maven_repository https://github.com/square/bazel_maven_repository. Disclosure: I maintain rules_jvm_external.
- swsieber 7y ago
  I very much doubt that it's faster than Gradle, but Gradle does do quite a bit more than Gradle.
  - christiangruber 7y ago
    It's not an absolute, but a contextual thing. For a clean build, on a single machine, under normal circumstances, gradle will often outperform bazel, because bazel pays a cost for isolation, parallelism infrastructure, and trying to max out your machine. OTOH, the abi-based compilation-avoidance, higher sensitivity to caching opportunities, and parallelism can make incremental builds much much faster on Bazel. Add in test-result-caching for non-flaky tests, and it's really a solid win for builds that don't invalidate most of the build graph. So it depends on (a) the shape of your graph, and (b) the nature of the change being built (e.g., does it invalidate a core library and all its downstream, or is it close to the app?). The other thing is remote build execution - the high focus on hermetic builds and parallelism makes building on a cluster of build workers extremely powerful, reducing build times, reducing load on developer machines, etc. And there are out-of-the-box solutions, initially from google on GCP to let you do this yourself. So... is bazel faster? Hell yeah, in some situations. Kinda in others. Not in some others. You need to think through what your development model is, your scale, how you construct (or want to construct) your build graphs, isolation of components, etc.
  - dikei 7y ago
    Bazel incremental build is much much faster than Gradle, if you follow the one-package-per-build rule.
- ceronman 7y ago
  For a mono-repo setup I find Bazel much better than those two. If you have few hundred projects or more, Maven is a pretty bad choice. Gradle is slightly better, but still much slower than Bazel. But it's not just speed, Bazel does do true CI: you make a change in a a lib and then you can immediately compile and run tests on anything that depends on that directly or indirectly. I have not been able to do that with Gradle, forget about Maven. Finally, if you use other languages, with shared artifact such as protobuf files, Bazel is simply amazing: change a proto file and recompile everything that depends on that on every language.
ceronman 7y ago
I've worked with both and while Bazel definetely has a learning curve, mostly because is very different than Maven and Gradle, I actually find it considerably simpler than those two. Maven dependency management is really complex, and I'm tired of dealing with dependency hell. And Gradle doubles down on Maven complexity where you stop having declarative XML config and instead have actual Groovy/Kotlin programs. So, please consider the difference between complex and unfamiliar.
- baylisscg 7y ago
  Speaking as someone who just got bitten by Maven’s dependency resolution now only building broken artefacts. (Sub-dependency’s dependency is loose enough to pull in a version built with an incompatible JDK) I prefer Bazel
maximente 7y ago
my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling. given that, as far as i can tell, there's nothing so compelling that it's worth switching over your project or organization. the tooling around maven is so good, and the inertia so strong (for my organization anyway), that there's no real incentive to switch. we've found that non-maven developers grumble a lot when forced to use it but then find the system, while verbose, is really solid. we are certainly not willing to throw that all away to play with google's latest cool thing.
- pjmlp 7y ago
  I grumbled a lot against Maven when my employer at the time decided to throw away our Ant build for Maven, considering that: - We actually made good use of Ant tasks and macros for having convention over configuration build infrastructure - Maven was still on 1.0 beta releases, with incomplete support for the plugins we required However this was more than 10 years ago, and nowadays I am yet to find something that beats Maven eco-system, specially given that I don't suffer from XML allergy, rather it is my favorite configuration format. I cry a little beat every time I have to wait for Android Gradle builds. Guess what, the upcoming Android Summit is enjoying yet another Gradle performance improvements talk. They can't get enough of them.

m0zg 7y ago

I don't work in Java, but just so you know, you can define Maven deps in your WORKSPACE file, and Bazel will automatically download and cache them (and their dependencies) much like Maven would. The rest of the build is trivial to set up.

oweiler 7y ago

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

jingwen 7y ago
The Bazel team published official rules for managing transitive dependencies from Maven: https://github.com/bazelbuild/rules_jvm_external https://github.com/bazelbuild/rules_jvm_external There are also community created solutions like https://github.com/johnynek/bazel-deps https://github.com/johnynek/bazel-deps, and https://github.com/square/bazel_maven_repository https://github.com/square/bazel_maven_repository. Disclosure: I maintain rules_jvm_external.
swsieber 7y ago
I very much doubt that it's faster than Gradle, but Gradle does do quite a bit more than Gradle.
- christiangruber 7y ago
  It's not an absolute, but a contextual thing. For a clean build, on a single machine, under normal circumstances, gradle will often outperform bazel, because bazel pays a cost for isolation, parallelism infrastructure, and trying to max out your machine. OTOH, the abi-based compilation-avoidance, higher sensitivity to caching opportunities, and parallelism can make incremental builds much much faster on Bazel. Add in test-result-caching for non-flaky tests, and it's really a solid win for builds that don't invalidate most of the build graph. So it depends on (a) the shape of your graph, and (b) the nature of the change being built (e.g., does it invalidate a core library and all its downstream, or is it close to the app?). The other thing is remote build execution - the high focus on hermetic builds and parallelism makes building on a cluster of build workers extremely powerful, reducing build times, reducing load on developer machines, etc. And there are out-of-the-box solutions, initially from google on GCP to let you do this yourself. So... is bazel faster? Hell yeah, in some situations. Kinda in others. Not in some others. You need to think through what your development model is, your scale, how you construct (or want to construct) your build graphs, isolation of components, etc.
- dikei 7y ago
  Bazel incremental build is much much faster than Gradle, if you follow the one-package-per-build rule.
ceronman 7y ago
For a mono-repo setup I find Bazel much better than those two. If you have few hundred projects or more, Maven is a pretty bad choice. Gradle is slightly better, but still much slower than Bazel. But it's not just speed, Bazel does do true CI: you make a change in a a lib and then you can immediately compile and run tests on anything that depends on that directly or indirectly. I have not been able to do that with Gradle, forget about Maven. Finally, if you use other languages, with shared artifact such as protobuf files, Bazel is simply amazing: change a proto file and recompile everything that depends on that on every language.

ceronman 7y ago

I've worked with both and while Bazel definetely has a learning curve, mostly because is very different than Maven and Gradle, I actually find it considerably simpler than those two. Maven dependency management is really complex, and I'm tired of dealing with dependency hell. And Gradle doubles down on Maven complexity where you stop having declarative XML config and instead have actual Groovy/Kotlin programs. So, please consider the difference between complex and unfamiliar.

baylisscg 7y ago
Speaking as someone who just got bitten by Maven’s dependency resolution now only building broken artefacts. (Sub-dependency’s dependency is loose enough to pull in a version built with an incompatible JDK) I prefer Bazel

maximente 7y ago

my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling. given that, as far as i can tell, there's nothing so compelling that it's worth switching over your project or organization. the tooling around maven is so good, and the inertia so strong (for my organization anyway), that there's no real incentive to switch. we've found that non-maven developers grumble a lot when forced to use it but then find the system, while verbose, is really solid. we are certainly not willing to throw that all away to play with google's latest cool thing.

pjmlp 7y ago
I grumbled a lot against Maven when my employer at the time decided to throw away our Ant build for Maven, considering that: - We actually made good use of Ant tasks and macros for having convention over configuration build infrastructure - Maven was still on 1.0 beta releases, with incomplete support for the plugins we required However this was more than 10 years ago, and nowadays I am yet to find something that beats Maven eco-system, specially given that I don't suffer from XML allergy, rather it is my favorite configuration format. I cry a little beat every time I have to wait for Android Gradle builds. Guess what, the upcoming Android Summit is enjoying yet another Gradle performance improvements talk. They can't get enough of them.