Yep, in this case, it is true. We used to use a rules engine, IBM JRules, we
retired it years ago and converted all of the rules into Groovy. It cost
6-figures annual support, forced us to use Oracle Weblogic, was extremely slow,
took a huge effort to map the data model into it so you could write
"English-like statements with it" and the whole "point" of it is that
non-developers could theoretically update it. Except programming is not hard
because learning Java/Groovy syntax is hard. The hard part is figuring out what
to do, regression testing, making it perform well, etc. So ultimately the
business farmed all of the edits out to the programmers, so instead of
programming in code, we program in some drag and drop interface with a
proprietary Eclipse plugin that only ran in an obsolete version of Eclipse and
it took 30 minutes to "compile". It's been a few years, but when I looked at
things like Drools, which looks closest to JRules I didn't see a drastic
difference to the architecture. In fact, that was the reason why we introduced
Groovy into the engine, now we have 1000s of Groovy files using STC for
performance and now rule engine times are in milliseconds instead of seconds
execution times. And we have a DSL syntax created that emulated the same
structure of the rules so we could largely copy/paste the code or generated
code into when {} then {} clauses. Except now it's all "real" code meaning we
get compile-time safety, find usages in IDE, refactoring, debugger, etc.
But, in the end, we still needed to have some data tables outside of the
structure, that the non-technical business stakeholders can and do maintain.
But there is some idea to be able to add simple expressions to that. Not to go
as far as a Drools decision table. But maybe. Even if we end up "re-inventing
the wheel" a little bit, we're still in a much better place.
I have had the thought of going all out and being able to upload entire Groovy
files as rules, then it really is like a rules engine. But it comes back to the
same problem - who is going to be editing this code, and this code is not going
to be in the IDE environment, using version control, etc. So, I expect this
still to be quite simple. Hence the choice of SPEL as alternative. But Groovy
has option of getting arbitrary complex, if we wish. I especially like creating
DSLs meant to be used with command chains and it would be a good ability. Based
on several responses here and no explicit warning from Jochen, it sounds like
we're not "abusing" Groovy to compile perhaps 100s of very small scripts. While
they can change on demand, it's likely not more than once a week. So
compilation time is not a concern. It's only a concern of metaspace overhead
(we are still on Java 8... but we do have a big heap) and execution performance.
Jason
Sensitivity: Internal
From: Edmond Kemokai <ekemo...@gmail.com>
Sent: Tuesday, October 27, 2020 6:09 PM
To: users@groovy.apache.org
Subject: Re: Groovy as expression parser
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
What you're building is a decision table, a common component in business
applications. I am not familiar with SPEL but it sounds like it will probably
serve your needs without the need for a full fledged programming environment.
You could also look into the various rules engines available for the JVM that
address the same problem.
https://www.baeldung.com/java-rule-engines<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.baeldung.com%2Fjava-rule-engines&data=04%7C01%7Cjason.winnebeck%40windstream.com%7Cdbcdd95c12a4408e84c108d87ac50961%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C0%7C0%7C637394334040194755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gT9Q56rzLoCnTATWpN6uIAob2J8x8rw92eBRy2nUfeI%3D&reserved=0>
Regards
Edmond
