E9.2 Teach a CNC - Why Groovy vs JRuby?

TFZ

TFZ

Well Known Member
So - just out of curiosity - as Oracle has been delivering JRuby instead of Groovy for close to two years now, why does it seem nobody is switching to JRuby? Is it not as versatile? Comfort? Does JRuby make widgets while Groovy makes gadgets (I honestly really don't know.)

I took a gander at google... and I see this debate has been raging...since 2007, and I got depressed about my career choices once again - but I digress!

I guess the main point is, with Oracle not really certifying groovy releases, what's going to be the best course to keeping current? Will uploading newer versions of groovy cause issues? And who's job is it to work on that? I think it's a joint effort, myself - but I know a good amount of tech admin folks have no desire. It feels like nobody is adopting JRuby in their Orchestrations in my customer base, and it purely just seems to be "because we're used to Groovy / someone showed us Groovy".
 
I think the decision as to which language to use depends on a couple of different things, such as the skillset of your developers, and the amount of existing groovy code in the environment that would need to be rewritten as JRuby if a customer wanted to switch from Groovy to JRuby. In my experience, clients who started creating orchestrations prior to 9.2.6 use groovy even after upgrading to a version where Ruby is an option. Customers who start using Orchestrator when JRuby became the default scripting language, use JRuby.

Working with both languages, I don't think there is a wrong choice. There are lots of resources available to help figure out how to do things in both languages. I haven't come across a situation where I wished I had the other language.

I am curious if you have come across any certification information for JRuby. I don't think Oracle ever changed the version of groovy they shipped from one tools release to the next, and I'm not sure if are/will with JRuby.
 
Kevin - thanks for the reply - I'm just going on the assumption that it's certified as it's included in the AIS par file. So - yep - it may be dated - but at least it comes with E1 now where groovy does not at all (but you have a nice facility to upload it!) I'm all for the flexibility, but customers do want some guidance on which way to go beyond going with whatever they're more comfortable with it. I did run across a doc the other day which basically adds a parm to the heap for startup for groovy related stuck threads that I hadn't seen before - and I've sort of stumbled down the rabbit hole.
 
I agree with Kevin, there probably is not a wrong choice. Having said that, if you are trying to decide I think I would go with Ruby (JRuby). In general, I believe it has always been way more popular than Groovy. I don't think Groovy really ever had much popularity.

The real question is why Oracle doesn't start supporting Python (Jython). Python is way more popular than Groovy or Ruby. Python also has a ton of utility - for just about any project Python is the 2nd best option :) . As of Jan 24, Python is #1 on the TIOBE index, Ruby is #18 and Groovy is..... lets see if I can find it.... not in the top 50 so not sure where it ranks.
 
It changed in 9.2.6 (someone is stating better performance and JRuby seems to be more popular)


Oracle claims it supports Groovy, JRuby and Jython, but it is a good question why JRuby seems to be the default, but the answer maybe above.


Oracle does have a fairly extensive library and resources to both Groovy and JRuby examples, but I've not seen any Jython.
I started doing ORCHs in JRuby before moving to Groovy. They are very similar in fairness.
 
Last edited:
Also found this

Ruby Now The Default Orchestrator Custom Coding Language, Not Groovy​

In our 3rd article on the Quest conference, we highlighted that JRuby is the default language for custom coding in Orchestrator going forward (not Groovy).
JRuby has a large development community, vast array of libraries and better run-time performance.

Both Groovy and Jython languages continue to be available with JDE Orchestrator, as they can still be installed on the AIS server.
…From Tools 9.2.6 JRuby will be pre-installed and Groovy script is being removed from E1 Delivery. Groovy will still be supported, however the groovy libraries will not be included. You can install it yourself by following the route in the Server Manager Guide….
 
Wow, great info.

In light of this I'll revise my view then, and state I wish Oracle would select Python as the default/standard. I am sure Oracle has their reasons though for picking Ruby. Their choice is certainly much more informed than my armchair opinion.

My only reason for wanting Python as the default is that Python is hugely popular and seems to only be gaining in popularity and has libraries to do pretty much anything. Personally I like learning a language that I can not only use for a specific purpose (in this case Orchestrator) but also has utility in other areas. IMO, this was always the big disincentive to investing a lot of effort into learning Groovy - outside of Orchestrator it really wasn't very useful.

Personally I have only done a little bit with Python and I seem to go long periods w/o using it so whenever I do I feel like I have to relearn everything. The more I learn the language though the more I like/hate it. I have never done anything with Ruby so don't really have an opinion on the language itself.
 
Yep I may change my tact and start looking more into JRuby and Jython more. When Oracle are stating performance as a reason for this, I guess it's good to take heed :)
 
Thanks everyone for the conversation, it has been extremely helpful. Typically, I'm being brought in after selection has been made and I get to figure out "why is it so slow". Luckily, 9 times out of 10 it's heap being poorly sized or security clean up - but it does lead to the conversation about groovy. I also had a few cases where I had to add extra libraries for old deprecated date time functions that used to work. I've been leaning towards telling people to go with what they're comfortable with - but I also have the folks who are new and don't even know where to start (where we all know the answer is google, of course.)
 
Reporting back, I "wrote" my first JSON conversion script using Jython. It's so much simpler than Groovy to do the same things, let alone bonus points if it's more performant. I'll keep trying it out for different situations
 
Reporting back, I "wrote" my first JSON conversion script using Jython. It's so much simpler than Groovy to do the same things, let alone bonus points if it's more performant. I'll keep trying it out for different situations
The question is, will you rewrite all of your existing groovy scripts in python, support two languages, or continue with groovy?
 
The question is, will you rewrite all of your existing groovy scripts in python, support two languages, or continue with groovy?
Our shop supports all 3 languages at the moment :D We have a rockstar cnc who doesn't mind the extra upkeep.

I think I'll try "drawing a line in the sand" and "writing" all scripts from here on out in jython just to see what it's like.
 
I think that's sort of key in all of this, I threw out a slide at inFocus on CNC getting more involved with this future as it's not really all about sitting around adjusting security and / or building packages anymore. I joked that usually everything winds up a CNC problem anyway, may as well get in front of it and let the truck hit you.... err... I mean adapt! That's it. Adapt.
 
I think that's sort of key in all of this, I threw out a slide at inFocus on CNC getting more involved with this future as it's not really all about sitting around adjusting security and / or building packages anymore. I joked that usually everything winds up a CNC problem anyway, may as well get in front of it and let the truck hit you.... err... I mean adapt! That's it. Adapt.
I haven't yet tried using Jython to try encoding JWT's yet, but the additional Java libs weneeded CNC to install and configure to work with groovy was 10000% essential to solving the problem. Definitely a solid place for openminded CNC's in the new frontier :D
 
Back
Top