The JVMCI code that Graal depends on was added to Java 9 and is inbuilt.
However, all Graal and Graal-downstream projects use a custom built Java 8 release. This is also the plan for the "foreseeable future" (https://github.com/oracle/truffleruby/issues/556#issuecommen...)
It looks like a bureaucratic struggle of some kind - I wonder what's the behind the scenes story at Oracle.
Additionally, "mx" : the build system that Graal uses is fairly funky - and everyone including Chris (the engineer that made this video) is trying to get the team to move on
Graal dev here. We're testing on jdk 8,9,10 and 11. We are packing graalvm with jdk 8 atm to keep variability reasonable. Graal will be integrated into the JVM soon with project Metropolis: http://openjdk.java.net/projects/metropolis/
Graal is used for many more things than dynamically compiling Java. Besides others it's used for SubstrateVM (closed world AOT compilation) and Truffle languages like TruffleRuby, Graal.JS, FastR, Sulong(llvm integration) and our newest member Graal.Python.
Graal comes out of Oracle Labs. The build tool mx is short for Maxine, the spiritual predecessor of the Graal project. If you don't know mx it's quite intimidating and ugly. It's Python written by Java developers. But it does it's job coping with our not so standard building and testing requirements. No we don't run mx on Graal.Python yet, but we are working on it for full build tool metacircularity ;).
It started as fork of Zippy. It changed very much since then. You can download the binary as part of graalvm. It's not yet open source, but it will be. It's just not ready yet.
I've been watching zippy for a while, unfortunately it relies heavily on Jython which is dead. Would be very interested to see progress on this! (And maybe contribute as well!)
Hi - thank you so much for posting here.
Please please get rid of MX. Please move to a better build tool - you will pull the ecosystem with you. And people will help you with that.
Secondly - I have not seen Graal Python anywhere. Is there a repo ? The GitHub project seems centred around Truffleruby. Graal Python would be awesome!
We have lots of infrastructure depending on mx. Infrastructure that no other build tool provides as far as I can tell.
In the end every build tool sucks. Sometimes you just need to be pragmatic. Mx integrates with maven pretty well and it generates ide config for intellij, eclipse and netbeans. Moving to a different system is probably not worth the cost atm. And it's not complicated to use at all. E.g mx build builds and mx gate builds and tests. Mx unittest runs unit tests.
As written below. Graal.Python is not yet open source. But you will hear from us soon.
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.
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.
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.
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.
When executing on Java we are dependent on hotspot to support it in the native bytecode interpreter. In truffle interpreters we made some successful experiments with tail calls emulated using exceptions. It's pretty slow in the interpreter but as soon as graal optimizes it, it just turns into a tailcall loop.
Here is some more info:
http://epub.jku.at/obvulihs/content/pageview/508465
You may find some blog posts about truffle and tailcalls as well.
It looks like a bureaucratic struggle of some kind - I wonder what's the behind the scenes story at Oracle.
Additionally, "mx" : the build system that Graal uses is fairly funky - and everyone including Chris (the engineer that made this video) is trying to get the team to move on
https://twitter.com/christhalinger/status/958824900004753408...
I wish they would use Bazel or something