3 ms·

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 s

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.

bitL 8y ago
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?
- weberc2 8y ago
  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.
  - miguro 8y ago
    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.
    - chrisseaton 8y ago
      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. http://chrisseaton.com/truffleruby/structs/ http://chrisseaton.com/truffleruby/structs/
  - mike_hearn 8y ago
    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.
- grashalm 8y ago
  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. This technique is based on some research we did in 2015: http://chrisseaton.com/rubytruffle/dls15-interop/dls15-interop.pdf http://chrisseaton.com/rubytruffle/dls15-interop/dls15-inter...
- BrandiATMuhkuh 8y ago
  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.
rch 8y ago
> CE is open source GPL. No comment beyond that but I thought I might save someone a few clicks.
- grashalm 8y ago
  I posted all the license below in a comment.

bitL 8y ago

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?

weberc2 8y ago
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.
- miguro 8y ago
  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.
  - chrisseaton 8y ago
    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. http://chrisseaton.com/truffleruby/structs/ http://chrisseaton.com/truffleruby/structs/
- mike_hearn 8y ago
  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.
grashalm 8y ago
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. This technique is based on some research we did in 2015: http://chrisseaton.com/rubytruffle/dls15-interop/dls15-interop.pdf http://chrisseaton.com/rubytruffle/dls15-interop/dls15-inter...
BrandiATMuhkuh 8y ago
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.

rch 8y ago

> CE is open source GPL. No comment beyond that but I thought I might save someone a few clicks.

grashalm 8y ago
I posted all the license below in a comment.