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

[TFZ]

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".

 

[Kevin Long]

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.

 

[TFZ]

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.

 

[BOster]

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.

 

[JohnDanter2]

It changed in 9.2.6 (someone is stating better performance and JRuby seems to be more popular)

Orchestrator Guide

Starting with Tools Release 9.2.6, the AIS Server is no longer preconfigured to create and run Groovy scripts. To edit or run existing Groovy scripts or to create new ones you must first configure the AIS servers with the Groovy libraries. This is also true for Jython. The AIS servers are...

docs.oracle.com

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.

Orchestrator Guide

Starting with Tools Release 9.2.5.4, orchestrations support JRuby and Jython as additional scripting languages along with Groovy.

docs.oracle.com

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.

 

[JohnDanter2]

Also found this

JET, JRuby, Logic Extensions & Workflows On The Glass - Ndevr

With JET, JRuby, Logic Extensions & Workflow Studio, Oracle give you the tools you need to reduce JD Edwards customisations & lower your TCO.

www.ndevr.com.au

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….

 

[BOster]

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.

 

[DaveWagoner]

agreed Brian, Python seems to be the gold standard language these days. Why not hop on the winning bandwagon if given the choice

 

[JohnDanter2]

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

 

[TFZ]

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.)

 

[DaveWagoner]

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

 

[Kevin Long]

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?

 

[DaveWagoner]

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 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.

 

[TFZ]

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.

 

[DaveWagoner]

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

 

[Stank1964]

I hate the whole chase involved with the hot language of the week (month, year...). Groovy seems like it was a bad idea, no surprise there based on the way development decisions seem to be made. I would have loved to listen to that debate at Oracle head quarters.

To me, even today, ORCH has clear signs of being loosely conceived and hastily pierced together for expedited delivery. That being said, I'm starting to love the thing and I get some very good work done with it.

The Oracle provided online resources have to get much more ramped up. I could never be as proficient with it as I am without jdelist and the very helpful posters!

 

[Kevin Long]

I hate the whole chase involved with the hot language of the week (month, year...). Groovy seems like it was a bad idea, no surprise there based on the way development decisions seem to be made. I would have loved to listen to that debate at Oracle head quarters.

To me, even today, ORCH has clear signs of being loosely conceived and hastily pierced together for expedited delivery. That being said, I'm starting to love the thing and I get some very good work done with it.

The Oracle provided online resources have to get much more ramped up. I could never be as proficient with it as I am without jdelist and the very helpful posters!

Given that Orchestrator was written by a bunch of Java developers, Groovy seemed like an obvious choice for a scripting language. I was actually surprised, but very pleased, that they started offering alternatives.

 

[jolly]

I don't think that custom requests, be they Groovy, Ruby or Python were ever intended for large complex or intensive jobs. They're just there to do some utility work (much of which can be done with LogicExtensions now). IMHO any custom request that doesn't fit in one screenshot is probably needing a rethink.

Which begs the philosophical question: what are custom request scripts really for? They are very good as JSON manipulating glue in an Orchestration. That's mostly what I use them for now. BSFNs custom requests are faster, LEX can do more stuff. Only custom scripts are good at JSON though.