GraalVM -- OR: How to handle alternative dependencies?

[ctrueden]

Lately I have been playing with the awesome GraalVM. It behaves like a JVM—and is currently built on OpenJDK 8—but includes polyglot support for languages built on the Truffle framework, such that all can run in the same VM with same data structures and performant JIT compilation.

As a proof of concept, I made a BeakerX notebook introducing GraalVM and playing with the polyglot functionality—it can be found here. However, there is no obvious way currently to declare an environment for this notebook for a couple of reasons:

1. GraalVM is not currently offered as a conda package. Certainly we could do this, at least for linux64 (the graalvm 1.0.0-rc1 community edition preview release is currently Linux-only).

2. But beakerx currently depends on openjdk, with no mechanism (that I know of) to swap to an alternative dependency that fulfills the same needs. (I tried this postBuild script to get it up and running on Binder, but it does not work as written unfortunately.)

So at the suggestion of @jakirkham, I am filing this issue to start a conversation about: A) how best to package GraalVM for conda; and B) how to handle alternative dependencies in general. Point (B) I'm sure arises in other contexts too—and for sure it matters for OpenJDK8 vs. OpenJDK9/10 etc. (#21).

What would be the best way to proceed for Graal? And does anyone here know about any plans to make conda more flexible regarding alternatives?

/cc @scottdraves

[mingwandroid]

What benefit does providing builds against a range of jdk versions bring?

[jakirkham]

I think that is off topic. That discussion can certainly be had, but is better scoped in issue ( #21 ) for instance.

The major question here is how can we supply GraalVM as an OpenJDK alternative. Currently we are packaging Zulu OpenJDK, which I gather we may want to replace with (or at least provide the alternative of) Intellij JDK as noted in issue ( #14 ). @sodre alluded to a selection mechanism in this comment, which sounds nice and what we may want to do here. Given @msarahan has been doing some work on this front with blas selection, maybe we can try the same approach here. Thoughts?

[jakirkham]

Forgot to mention issue ( conda-forge/conda-forge.github.io#587 ), which discusses a similar selection problem with MPI that @mcg1969 and others have worked on.

[jakirkham]

cc @kalefranz @msarahan

[timsnyder]

@jakirkham this topic is coming up for me because I need to use graalvm as the JDK compiling my Chisel HDL through Scala into Java. I still don't see any conda-forge packages with graal in the name but perhaps I'm not looking in the right way?