bazel is not used on android because it came later. However, lots of startups are using it to build both their android+ios apps in production in CI/CD. here's the android toolchain - https://docs.bazel.build/versions/master/tutorial/android-ap...

that's a bit of fud that it is restricted to googleplex, not sure why you would say that.

https://github.com/bazelbuild/bazel/wiki/Bazel-Users - bazel is being used at tons of places including Dropbox, Asana, Etsy, Huawei, Pinterest, Uber, etc. for multiple languages - Java, Rust, Golang, C++, etc.

Again - I'm not sure why you are mentioning about a "new JIT compiler". Graal on Java 9 works - if you check a ton of documentation, everyone is talking about using Graal on Java 9 (self-built). E.g. http://chrisseaton.com/rubytruffle/jokerconf17/

I'm talking about Oracle + Graal project not putting out Java 9 based releases because of a co-ordination effort.

Add to that list SpaceX. Guys from SpaceX showed in Bazel conference they are using Bazel to build their software.

> However, lots of startups are using it to build both their android+ios apps in production in CI/CD.

Keyword here is startups, with freedom to use alternative tech just because.

Apparently Android Studio is work in progress, and doesn't support all the features, like the NDK.

https://ij.bazel.build/docs/bazel-plugin.html

I really don't see the need to use anything else other than Maven, unless it really substantially improves the build speed and IDE tooling experience.

If it wasn't for Google's imposition of Gradle on us, I wouldn't bother with it.

However if in an imaginary future, they replace Gradle with Bazel and those points are met (build speed and tooling) then by all means.

> I'm talking about Oracle + Graal project not putting out Java 9 based releases because of a co-ordination effort.

It is already there on Linux x64 for 9, with macOS and Windows on 10, as mentioned on the talk, so I really don't follow.

Even if we agree it's true, it's still more than mx. And that was the whole point. MX is a pain to setup and use - if you don't want Bazel, then fine. But then use cmake or waf or scons or gradle or one of the many build tools that make this possible...and more importantly are more widely used and have a ton of help threads and documentation already.

AFAIK Bazel is the best fit because of automatic download of dependencies from many source repos.

About java 9 - it's not officially supported. You have to build your own. Please read the GitHub link I posted in my original comment.

That is about OpenJDK, the official Linux x64 binaries have it.

As mentioned on the talk, all the binary downloads with AOT support, have Graal.

When the commercial JDK moves into OpenJDK as planned, that will most certainly no longer be an issue.

not sure what you mean by that.

All official Graal releases are based on top of JDK8 - http://www.oracle.com/technetwork/oracle-labs/program-langua...

JDK 9 supports it - however the build and release needs some kind of Oracle-level coordination. I'm not sure if this has anything to do with OpenJDK. But happy to be corrected.

Video, at minute 5, "Where do I get it":

JEP 295: Ahead-of-Time Compilation http://openjdk.java.net/jeps/295

"The project will merge Graal core into the JDK, and deliver it in Linux/x64 builds."

OpenJDK is not the JDK one downloads from http://www.oracle.com/technetwork/java/javase/downloads/jdk9....

Also there are many Graals so to say, the research being done at Oracle labs, the rewriting of the JVM replacing C++ with Java (Metropolis) and the piecewise integration into the official JDK.

So I don't find it strange to have some kind of Oracle-level coordination.

Yes I do agree it is annoying, but from my humble point of view it is a situation that when everything has moved into the OpenJDK, with AOT compilation supported across all three major desktop OSes, the situation will be sorted out in the meantime.

And we are only speaking of Oracle here, there a few other dozen vendors that most likely will never have something like Graal on their JVMs.

> I really don't see the need to use anything else other than Maven, unless it really substantially improves the build speed and IDE tooling experience.

If all you need is build speed why not fall back to ANT scripts?

I am sorry to disappoint you but If it wasn’t for ANT, I’d say Maven is one of the worst build tools out there (at least as far as Java ecosystem is concerned).

Build speed of any decent Maven project is nothing to sneeze at. Grade, while slightly slower at startup is consistently faster at dev time because it can actually do proper incremental build. And it is miles easier for dev tools to integrate with because its build model is actually immutable, which is a major point why Gradle IDE integrations don’t actually suck when compared to Maven.

It’s funny how Maven is considered to be more declarative because of the XML syntax of the POM files while the underpinning technology is ultimately much more dynamic and mutable than Gradle’s. While Gradle which chose dynamic and malleable language like Groovy for the syntactic front end is much more declarative and immutable of the two.

I've use the unofficial Android Maven plugin before the official Gradle plugin was released. When the Gradle plugin came out, it made my builds so much simpler than it used to be with Maven. As much as I like XML, having 4 lines per dependency is way too much. And having to write a custom plugin every time you want some custom logic is terrible. The Maven ecosystem may have increased since then, but I'm very glad they chose Gradle over Maven.

The beauty of XML is that is designed for tooling, not to be written by hand.

So for me adding a dependency is just a matter of using the graphical tooling in Eclipse and Netbeans.

All major headaches I "enjoyed" with Maven was custom logic coming from Ant scripts, from team not willing to adopt a more declarative way of designing their projects.

With Gradle, I get the same mess Ant used to be, just slower.

I shouldn't be getting nerd sniped by comment about Maven but here goes. Maven doesn't compose because it is an ad-hoc lisp where every element has different semantics, every element is a different language. This isn't an XML problem, but a way that XML fragments in Maven map to the interpreters of those fragments. Maven could have been an amazingly compact expressive combination of a logic/constraint solver with a declarative language, instead it is PHP written in XML. Maven is declarative only in that it has a textual interface.

My disclaimer: my coworkers are using Scala and SBT. Gradle + Java isn't slower than Ant or Maven. Gradle + Kotlin is a little slower, they just need to make the annotation processors incremental.

But for Java, incremental builds with compiler avoidance combined with the build cache, parallel builds (incubating features close to maturity) mean I write more sophisticated, easier to maintain builds than I ever have with Maven.

Something awesome would be to have a S-expression to Maven XML transpiler. Parens instead of xml tags. Is there something like that?

Not a transpiler, but we use something similar all the time in Clojureland.

https://leiningen.org

It can easily be used as a Java build tool.

You could do something like that with polygot-maven.

https://github.com/takari/polyglot-maven

The encoding (XML) isn't Maven's problem, the semantics are.