Python as a scripting language using GraalPython

@javahippie Now I may have a real GraalVM Polyglot -project with questions:

As Python is my native language, some time ago I played with the idea of being able to use modern Python as a scripting language in processes. So far, only Jython implementation has been supported.

I’ve learned that scripting support is in the BPM engine is based on javax.script.ScriptEngineFactory. Is this still correct?

Unfortunately, unlike GraalJS, GraalPy does not ship with javax.script.ScriptEngineFactory. Therefore, I tried to follow GraalJS to implement my own:

Besides all the possible mistakes / misunderstandings around ScriptEngineFactory / Polyglot, I had an issue with slow script execution, because of every task starting their own GraalPy-context. Next, I believe I just tried to follow GraalJS, I refactored it to reuse the same context, but clear all the variables between executions. This feels a bit fragile, and possibly there is a better way?

Next, I’ll try to build native Robot Framework script task support on top of this Python support. Meanwhile I should also try to write some tests, unless I am completely wrong in relying on ScriptEngine-feature.

How does this all sound to you?

2 Likes

The whole thing is a little tricky. You are right, that the ScriptEngineFactory (JSR-223) was the only solution in the engine for a long time. Due to incompatibilities, Camunda added support for Graal.js at least: https://jira.camunda.com/browse/CAM-13516

Similar changes happened around JRuby, making the current JRuby version (which is now also built on Truffle) incompatible with Camunda, that’s a low prio ticket we have right now, as the older JRuby version has some security issues.

In the long term it might be a good idea to migrate all language support for scripting entirely to the Truffle Polyglot API - but this does not help you right now. The ScriptEngine was always thought of as a crutch, and the GraalVM team recommended it as a bridge, not a permanent solution. This would enable us to use a ton of script languages, including everything that compiles to LLVM, WebAssembly, even Java itself.

Reusing the context would have been my first instinct, too. Context creation is expensive and while execution speed is not that critical for many process applications, it would still be annoying for some and damaging for others.

I will have to think about this for some time, or reach out to some people I know at Oracle, who know this stuff in and out.

2 Likes