Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: