Matt, I don't use JRuby, but the reason it raised my eyebrow a little was that AFAIK JRuby is the complete opposite of Jython in terms of enterprise readiness and parity with its C-based counterpart.
Edward, The problem with Lua here is that the Java versions of Lua aren't being maintained. I think the most recent release on any branch of them was 3 years ago. They're basically dead in the water as projects. On Mon, Nov 6, 2023 at 2:57 PM Edward Armes <edward.ar...@gmail.com> wrote: > While I do like the ExecuteScript processors as they are great at digging > you out of a hole. The performance of them isn't that great. > > That being said I would ve careful about dropping Lua support as there is a > growing list of software that supports end user/administrator extensions > via Lua for those that don't want to have to re-compile software > themselves. On the other hand given that Jython doesn't yet have a Python 3 > implementation it could be argued dropping Jython support is a must given > that the Python 2.x line is basically end of life. > > Now I wonder if its worth re-factoring the ExecuteScript processors to be > per language implementations inheriting from a common base like a few > processors do already. > > Edward > > On Mon, 6 Nov 2023, 16:24 Matt Burgess, <mattyb...@apache.org> wrote: > > > I believe it is because in both ExecuteScript and ExecuteGroovyScript > > you can do "regular" groovy, but EGS has extra built-ins such as easy > > access to controller services, Groovy SQL stuff, etc, and we could > > keep building it out. But IMO we'd have to port the rest of the > > scripted components (ScriptedReader/Writer, etc.) over to the Groovy > > bundle and make sure there's a drop-in replacement in the Python stuff > > before we'd want to deprecate the scripted bundle. > > > > On the JRuby front, is that something you use actively? This question > > is for you and the entire community of course. > > > > Regards, > > Matt > > > > On Mon, Nov 6, 2023 at 7:12 AM Mike Thomsen <mikerthom...@gmail.com> > > wrote: > > > > > > If we deprecate ExecuteScript, I think we need to have groovyx be ready > > to > > > function as a drop-in replacement if it's not there already. > > > > > > On Sun, Nov 5, 2023 at 9:21 PM Matt Burgess <mattyb...@apache.org> > > wrote: > > > > > > > IIRC the removal of these engines was mostly due to lack of use or at > > > > least the perception thereof. If JRuby is being used by the community > > > > actively, I'm happy to revisit that discussion. Luaj's JSR-223 > > > > interface left something to be desired, but JRuby just needed a > system > > > > variable set or something like that. > > > > > > > > For the groovyx bundle, because it is Groovy-specific I tend to think > > > > we could make better use of that than ExecuteScript, especially if we > > > > do get rid of all the engines. We have a Groovy-specific processor, a > > > > "real" Python SDK, and no more Nashorn. Perhaps we move all the > > > > scripted components to the Groovy bundle, although I believe some > > > > folks still make use of Jython for these. Of course if we reinstate > > > > JRuby for ExecuteScript it's probably best to keep things the way > they > > > > are, or create a jruby bundle. The original scripting bundle was > > > > aiming to support several engines, but if it turns out only one or > two > > > > will be useful, it may not be worth shoehorning all that JSR-223 > logic > > > > when engine-specific components could be simpler, more easily > > > > maintained, and allow for the idioms of the language to be better > used > > > > (as is done in the groovyx bundle). > > > > > > > > Just my two cents, looking forward to everyone's thoughts! > > > > > > > > - Matt > > > > > > > > On Sun, Nov 5, 2023 at 8:31 PM Mike Thomsen <mikerthom...@gmail.com> > > > > wrote: > > > > > > > > > > https://issues.apache.org/jira/browse/NIFI-11646 > > > > > > > > > > I get the removal of Lua, but not the removal of JRuby. It's a > clean > > > > > reimplementation of Ruby native to the JVM and AFAICT is pound for > > pound > > > > as > > > > > actively maintained as Groovy. > > > > > > > > > > Also, at this point, does it make sense to even keep the groovyx > > bundle > > > > > rather than deprecate it for 2.X? > > > > > > >
