The reason why we don't build CE on Mac OS is purely technical. Its because there was no OpenJDK 8 build for Mac that we could use. We hope we can change that soon. OpenJDK builds got a lot more regular with Java version >= 10.
Currently we have the same APIs for CE and EE. So applications are easily portable between those two. We have no plans to change this.
But. You don't have to take our word for it. CE is open source and you may build, extend and maintain it yourself if you want to.
Is it Oracle Oracle, or Oracle SUN product? BTW, it sounds pretty cool, I am wondering how do you convert between complex datatypes while passing parameters between different languages and not losing much speed with it?
We don't convert. We have defined a contract that all languages can work with (quite a challenge and still evolving).
From the website:
> In order to provide foreign polyglot values meaning in languages we have developed the so-called polyglot interoperability protocol. This interoperability protocol consists of a set of standardized messages that every Graal language implements and uses for foreign polyglot values. The protocol allows GraalVM to support interoperability between any combination of languages without requiring them to know of each other.
Coincidentally I met the creators last week and it's actually developed at the Johannes Kepler University in Linz/Austria. They have a oracle sponsored lab working on compilers etc.
Me too. I’m thinking there must be some library that knows how to marshal between object representations. Surely Graal doesn’t have universal objects that suit every language.
That's the thing - there is no marshaling. The objects are passed between the languages as pointers under-the-hood. There is a standard way of invoking methods/functions on those pointers, that works across all languages.
To give you an idea of how deep this goes - you can pass a Ruby object to a C function and the C function can read and write it as if it was a pointer to a structure.
It has a form of universal object used for scripting languages (but not more static languages like Java or C++). But using it is not required, it's just a convenience to make implementing languages easier.
What it actually provides is a form of "universal abstract syntax tree". So if a C program wants to access a JavaScript object by writing "a->b = c" then the dereference is turned into a snippet of JavaScript code (in effect) and inlined right into the C function.
Currently we have the same APIs for CE and EE. So applications are easily portable between those two. We have no plans to change this.
But. You don't have to take our word for it. CE is open source and you may build, extend and maintain it yourself if you want to.