8 ms·

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

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#issuecomment-335118818 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 https://twitter.com/christhalinger/status/958824900004753408?s=09 https://twitter.com/christhalinger/status/958824900004753408... I wish they would use Bazel or something

pjmlp 9y ago
Nothing, beyond the herculean effort that is to add a new JIT compiler, while keeping up everything else running without regressions. Graal's work is well known since the days of MaxineVM. Hopefully eventually everything will be sorted out. For similar comparison, Microsoft is also having multiple year/releases effort with RyuJIT, .NET Native and CoreRT. Thankfully Bazel is mostly restrained to Googleplex stuff. It is already a pain on Android, measured in cups of coffee/tea per developer, that they went with Gradle instead of Maven.
- sandGorgon 9y ago
  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-app.html 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 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/ 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.
  - pjmlp 9y ago
    > 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 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.
    - sandGorgon 9y ago
      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.
      - pjmlp 9y ago
        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.
        sandGorgon 9y ago
        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-languages/overview/index.html 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.
- matharmin 9y ago
  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.
  - jxub 9y ago
    Something awesome would be to have a S-expression to Maven XML transpiler. Parens instead of xml tags. Is there something like that?
    - divs1210 9y ago
      Not a transpiler, but we use something similar all the time in Clojureland. https://leiningen.org https://leiningen.org It can easily be used as a Java build tool.
    - sitkack 9y ago
      The encoding (XML) isn't Maven's problem, the semantics are.
    - papercrane 9y ago
      You could do something like that with polygot-maven. https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven
  - pjmlp 9y ago
    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.
    - 9y ago
grashalm01 9y ago
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/ 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 ;).
- AlphaSite 9y ago
  Why not Graal.py?
  - grashalm01 9y ago
    Good idea. The name is not final.
  - alcidesfonseca 9y ago
    For me this would mean a python project (graal bindings within CPython) and not a Python implementation. CPython Pypy Jython IronPython I would now go with GraalPython (GrPython or GPython)
    - marvy 9y ago
      Graal.py rubbed me the wrong way, until I read your comment I couldn't put my finger on why. Thank you!
    - AlphaSite 9y ago
      Its more symmetry with Graal.js
- 9y ago

pjmlp 9y ago

Nothing, beyond the herculean effort that is to add a new JIT compiler, while keeping up everything else running without regressions. Graal's work is well known since the days of MaxineVM. Hopefully eventually everything will be sorted out. For similar comparison, Microsoft is also having multiple year/releases effort with RyuJIT, .NET Native and CoreRT. Thankfully Bazel is mostly restrained to Googleplex stuff. It is already a pain on Android, measured in cups of coffee/tea per developer, that they went with Gradle instead of Maven.

sandGorgon 9y ago
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-app.html 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 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/ 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.
- pjmlp 9y ago
  > 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 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.
  - sandGorgon 9y ago
    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.
    - pjmlp 9y ago
      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.
      - sandGorgon 9y ago
        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-languages/overview/index.html 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.
matharmin 9y ago
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.
- jxub 9y ago
  Something awesome would be to have a S-expression to Maven XML transpiler. Parens instead of xml tags. Is there something like that?
  - divs1210 9y ago
    Not a transpiler, but we use something similar all the time in Clojureland. https://leiningen.org https://leiningen.org It can easily be used as a Java build tool.
  - sitkack 9y ago
    The encoding (XML) isn't Maven's problem, the semantics are.
  - papercrane 9y ago
    You could do something like that with polygot-maven. https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven
- pjmlp 9y ago
  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.
  - 9y ago

grashalm01 9y ago

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/ 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 ;).

AlphaSite 9y ago
Why not Graal.py?
- grashalm01 9y ago
  Good idea. The name is not final.
- alcidesfonseca 9y ago
  For me this would mean a python project (graal bindings within CPython) and not a Python implementation. CPython Pypy Jython IronPython I would now go with GraalPython (GrPython or GPython)
  - marvy 9y ago
    Graal.py rubbed me the wrong way, until I read your comment I couldn't put my finger on why. Thank you!
  - AlphaSite 9y ago
    Its more symmetry with Graal.js
9y ago