Mike, As an alternative it might be worth looking into a processor specifically for Kotlin like we have with ExecuteGroovyScript (EGS). ExecuteGroovyScript doesn't use JSR-223 and instead goes right for the GroovyShell. This allows for cool things like Groovy-specific idioms and helpful "meta-capabilities" such as redirect I/O to/from FlowFile objects. Depending on how they've done their entry point(s), an ExecuteKotlinScript processor could leverage compiled scripts without needing the JSR-223 impl, as well as adding some Kotlin-ness to the scripting capabilities. I hesitate to suggest this for any of the other scripting languages but as Kotlin becomes more popular and given its tight integration with the JVM (vs Jython for example), that might be the way to go.
Regards, Matt On Sun, Nov 6, 2022 at 6:16 PM Mike Thomsen <mikerthom...@gmail.com> wrote: > > I finally chased down the behavior differences that I found and > discussed with Matt in the previous PR. Kotlin's got very promising > (long term) JSR223 support but with a few caveats in the short term: > > 1. Its ScriptEngine does not support ScriptEngine#get properly, so any > component that uses get(String) to fetch an object defined in a script > won't work with Kotlin (ex InvokeScriptedProcessor). > 2. Invocable vs Compilable have very different behaviors WRT bindings. > 3. Until Kotlin's JSR223 engine matures, we'd probably need to limit > it to ExecuteScript with extra documentation explaining that it > doesn't behave quite as expected. > > What I figured out, and it makes sense given how Kotlin works, is that > bindings cannot be used to provide dynamic injection of variables. So > just calling "session" as an implied ProcessSession won't work. You > have to do something like this: > > val session = bindings["session"] as ProcessSession > > Either on your own or in a setup block for every script. > > I feel like there's value here, but wanted to throw it out there to > other devs before going down the process of finalizing the > ExecuteScript support and starting to exclude it from the other > components. > > On a side note, we might want to add an InvokeCompiledScript processor > that's like InvokeScriptedProcessor but is designed for Kotlin, JRuby > and Groovy which work really well with taking scripts down to Java > byte code and working with streamlined fat jars. Could be another > angle on simplifying deployments of scripts and script-like > components. > > Thanks, > > Mike
